Comments 43
Я думаю, написанное тут можно в равной степени отнести и к Ruby, и к PHP — все эти инструменты по производительности примерно в одной «весовой категории».
Недавно мне попалась статья «Twitter on Scala» — это интервью с разработчиками Twitter'а, в котором они рассказывают о том, что сейчас переписывают почти всё на Scala, оставляя на Ruby только отдачу контента пользователю. По их словам, это позволило и достичь производительности, и продолжить получать от программирования удовольствие. Вот цитата из интервью:
Хочется узнать, есть ли у кого из хабралюдей опыт его реального использования на практике? Какие впечатления?
Недавно мне попалась статья «Twitter on Scala» — это интервью с разработчиками Twitter'а, в котором они рассказывают о том, что сейчас переписывают почти всё на Scala, оставляя на Ruby только отдачу контента пользователю. По их словам, это позволило и достичь производительности, и продолжить получать от программирования удовольствие. Вот цитата из интервью:
The other big reason we looked at Scala was that, although we’ve run into problems with Ruby, we like the flexibility of the language. We like that it’s such a full featured language, that it’s fun to code in. It’s the same reason so many Java people end up writing Ruby after they leave some big enterprise company. They want to have fun day to day. We didn’t want to leave that behind and go to a language with a very dry, businesslike community, like C++, for example. We know that people write super high performance code in C++, and engineers like Steve and Robey have had experience with that. But we wanted to be using a language that we’re really passionate about, and it seemed worth taking a gamble on Scala.Язык действительно интересный, и пока я читал о нём в основном только хорошее (на забугорных сайтах). Код Scala компилируется в байткод JVM или .NET, и позволяет использовать уже написанные для Java/.NET классы, если родных инструментов Scala не хватает.
Хочется узнать, есть ли у кого из хабралюдей опыт его реального использования на практике? Какие впечатления?
ну вот php-то как раз пока с вопросом «Что мы будем делать, если целая планета решит что наш новый сервис офигителен?» справляется вполне достойно
Переездом на более мощную аппаратную конфигурацию?
Можно пример? Только не говорите Facebook или Last.fm — кишки там все равно на Java и прочих.
пруф кишок на джава у фейсбука. там php+mysql+memcached патченый и erlang для чата
Ну, может когда-то давно там действительно всё работало на php + mysql + memcached.
Однако летом 2008-го Facebook открыл исходники своего проекта Cassandra. Это их собственный аналог Google BigTable, написанный, кстати, на Java. К тому моменту, только под поиск было задействовано уже несколько сотен серверов (600+ ядер) c Cassandra (пруфлинк).
Похоже что Java действительно используется в «кишках» Facebook, причём основательно. Как и erlang, как и всё что удачно подходит для решения поставленных задач.
Не стоит считать Facebook апологетом PHP. Возможно это просто «тяжелое наследие» прошлого, когда сайт был молодым стартапом.
Однако летом 2008-го Facebook открыл исходники своего проекта Cassandra. Это их собственный аналог Google BigTable, написанный, кстати, на Java. К тому моменту, только под поиск было задействовано уже несколько сотен серверов (600+ ядер) c Cassandra (пруфлинк).
Похоже что Java действительно используется в «кишках» Facebook, причём основательно. Как и erlang, как и всё что удачно подходит для решения поставленных задач.
Не стоит считать Facebook апологетом PHP. Возможно это просто «тяжелое наследие» прошлого, когда сайт был молодым стартапом.
спасибо! :)
Ещё red5 видео-сервер, hadoop/hive для распределённых вычислений.
вопрос такой — а на python вы бы и видео-сервер, и распределённые вычисления и информацию бы хранили всё без сторонних сервисов? ну-ну. вы путаете тёплое с мягким сейчас.
Причём здесь Python? Человек спросил, где Java в Facebook, — я ответил.
Тогда почему я не могу привести пример Фейсбука, в качестве примера сайта изначально написанного на php, а потом удачно смасштабированного?
Переписывание огромной части на другом языке трудно назвать «удачной маштабированностью».
можно, можно и для любого другого языка, если воткнуть тысячу серверов и миллиарды инвестиций :)
Да вы что угодно можете делать, если знаете, о чём говорите. Я в своё время с удовольствием послушал презентацию об архитектуре Facebook и роли PHP на прошлогоднем Qcon.
недавно в сеть утёк фасад довольно свежей версии фейсбука и написан он на php. заявлять то, что в фейсбуке используется Java, потому что там для хранения информации используется Cassandra, это всё равно, что говорить, что в кишках любого сайта на php/mysql — c и c++
Ну, допустим, чтобы рассуждать о кишках — надо точно знать архитектуру этих проектов. вы же её вряд ли знаете.
facebook, flickr, digg, wikipedia — во всех этих проектах highload-бомбардировке подвергаются php скрипты, то что php на этих сайтах юзает какие-то скомпилированные участки кода — так это вполне нормально. каждая технология занимается своим делом.
вопрос только стоял по-другому: не где, что юзается в данный момент, а «Что мы будем делать, если целая планета решит что наш новый сервис офигителен?» — вышеприведённые сайты — как раз и отвечают на этот вопрос. У каждого своя success story, а роднит их то, что изначально они были написаны на чистом php.
facebook, flickr, digg, wikipedia — во всех этих проектах highload-бомбардировке подвергаются php скрипты, то что php на этих сайтах юзает какие-то скомпилированные участки кода — так это вполне нормально. каждая технология занимается своим делом.
вопрос только стоял по-другому: не где, что юзается в данный момент, а «Что мы будем делать, если целая планета решит что наш новый сервис офигителен?» — вышеприведённые сайты — как раз и отвечают на этот вопрос. У каждого своя success story, а роднит их то, что изначально они были написаны на чистом php.
«Что мы будем делать, если целая планета решит что наш новый php-сервис офигителен? — Перепишем все мелденные части на C++, а php будет отдавать блоки из memcached.»
> Ну, допустим, чтобы рассуждать о кишках — надо точно знать архитектуру этих проектов. вы же её вряд ли знаете.
Свои слова я могу подкрепить фактами. Вы же своё предположение о моих знаниях можете чем-то подкрепить?
> facebook, flickr, digg, wikipedia — во всех этих проектах highload-бомбардировке подвергаются php скрипты, то что php на этих сайтах юзает какие-то скомпилированные участки кода — так это вполне нормально. каждая технология занимается своим делом.
PHP — шаблонизатор. В той же Википедии за поиск отвечает Java(Apache Lucene), бомбардировку на самом деле выдерживает memcached/mysql, PHP лишь изредка меняет данные и обновляет кеш странички.
> вопрос только стоял по-другому: не где, что юзается в данный момент, а «Что мы будем делать, если целая планета решит что наш новый сервис офигителен?» — вышеприведённые сайты — как раз и отвечают на этот вопрос. У каждого своя success story, а роднит их то, что изначально они были написаны на чистом php.
«success story» по-русски это «история успеха». PHP справляется ничем не лучше Python, Perl, Ruby… Он отрабатывает пол-секунды, за которую берёт данные из кеша/бекенда или отправляет запрос на его обновление. Другое дело, что 5+ лет назад, когда эти сервисы пускались, альтернативы PHP не было, сейчас же — пожалуйста.
Facebook, Flickr & Wikipedia отвечают как раз тем, что PHP, или не PHP: разницы нет никакой, но я лично был бы рад видеть MediaWiki написанным на Rails/Django/Grails — уж больно страшные исходники в архиве MediaWiki, и не говорите, что это не так.
Свои слова я могу подкрепить фактами. Вы же своё предположение о моих знаниях можете чем-то подкрепить?
> facebook, flickr, digg, wikipedia — во всех этих проектах highload-бомбардировке подвергаются php скрипты, то что php на этих сайтах юзает какие-то скомпилированные участки кода — так это вполне нормально. каждая технология занимается своим делом.
PHP — шаблонизатор. В той же Википедии за поиск отвечает Java(Apache Lucene), бомбардировку на самом деле выдерживает memcached/mysql, PHP лишь изредка меняет данные и обновляет кеш странички.
> вопрос только стоял по-другому: не где, что юзается в данный момент, а «Что мы будем делать, если целая планета решит что наш новый сервис офигителен?» — вышеприведённые сайты — как раз и отвечают на этот вопрос. У каждого своя success story, а роднит их то, что изначально они были написаны на чистом php.
«success story» по-русски это «история успеха». PHP справляется ничем не лучше Python, Perl, Ruby… Он отрабатывает пол-секунды, за которую берёт данные из кеша/бекенда или отправляет запрос на его обновление. Другое дело, что 5+ лет назад, когда эти сервисы пускались, альтернативы PHP не было, сейчас же — пожалуйста.
Facebook, Flickr & Wikipedia отвечают как раз тем, что PHP, или не PHP: разницы нет никакой, но я лично был бы рад видеть MediaWiki написанным на Rails/Django/Grails — уж больно страшные исходники в архиве MediaWiki, и не говорите, что это не так.
«Полсекунды» на то чтобы взять данные из кэша и отправить запрос на обновление — это оставьте Ruby или Python-у. PHP справляется в сотни раз быстрее, что собственно я и хотел сказать.
В этом и есть разница, почему там PHP, а не Python/Ruby — в этой половине секунды. (согласитесь, что разработчики этих сайтов не дураки, и раз написали производительные бэкенды и им всё равно пришлось переписывать фасад, то почему они снова выбрали пых, хотя вроде и более славные альтернативы к этому времени появились?)
В этом и есть разница, почему там PHP, а не Python/Ruby — в этой половине секунды. (согласитесь, что разработчики этих сайтов не дураки, и раз написали производительные бэкенды и им всё равно пришлось переписывать фасад, то почему они снова выбрали пых, хотя вроде и более славные альтернативы к этому времени появились?)
Я проводил небольшое сравнительное тестирование PHP, Python, Ruby, Perl и еще некоторых языков. Порядок величины «время работы скрипта» для простых операций везде одинаковый. Простые операции — это отдать кешированные данные, сделать десяток запросов в базу и т.д. А вот время запуска скрипта различается очень сильно, но это уже проблема не языка, а связки с сервером. Например, mod_php работает быстрее mod_python, а mod_wsgi быстрее mod_php. Разница — десятки процентов. Запуск через CGI на порядок медленнее. Утверждение, что PHP с чем-то «справляется в сотни раз быстрее» — полный бред. Попробуйте потестировать или поискать в интернете результаты тестов.
во-первых, «сотни раз быстрее» я говорил про пассаж всезнающего человека о половине секунды, которую тратит php на операцию выдачи страницу в фейсбуке или любом другом сайте.
во-вторых, синтетические тесты — зло. смею заметить, что в ваших тестах «отдать кэшированные данные» и «сделать запросы в базу данных», языки тоже не причём. просто потому, что все они полагаются на драйвера связок с кэшем и базой данных.
во-вторых, синтетические тесты — зло. смею заметить, что в ваших тестах «отдать кэшированные данные» и «сделать запросы в базу данных», языки тоже не причём. просто потому, что все они полагаются на драйвера связок с кэшем и базой данных.
«полсекунды» было названо явно с потолка. так как производительность РНР в лучшем случае сравнима с пайтоновской.
в худшем — уступает.
shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=php&lang2=python&box=1
в худшем — уступает.
shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=php&lang2=python&box=1
Потому что рулит не код, а люди. Для изменения языка проекта необходимо на него пересадить своих разработчиков. А значит можно потерять людей, оставшиеся будут новичками в новом языке. Можно нанять профессионалов целевого языка, но эти люди не в курсе проблем проекта.
Использовать PHP или погубить проект это не выбор. Факт не свидетельствует о качестве языка и не должен использоваться при выборе языка для нового проекта.
Использовать PHP или погубить проект это не выбор. Факт не свидетельствует о качестве языка и не должен использоваться при выборе языка для нового проекта.
>«Полсекунды» на то чтобы взять данные из кэша и отправить запрос на обновление — это оставьте Ruby или Python-у. PHP справляется в сотни раз быстрее, что собственно я и хотел сказать.
Полсекунды это разумеется общее понятие, по сравнению c Java и прочими бекендами, которые работают часами/днями/месяцами. Или же ваше «в сотни раз быстрее полсекунды» является универсальной оценкой для любой операции на любом PHP-сайте?
> В этом и есть разница, почему там PHP, а не Python/Ruby — в этой половине секунды.
Разницы никакой — Twitter(Rails) & Facebook(PHP) & YouTube(Python) работают одинаково быстро.
> (согласитесь, что разработчики этих сайтов не дураки, и раз написали производительные бэкенды и им всё равно пришлось переписывать фасад, то почему они снова выбрали пых, хотя вроде и более славные альтернативы к этому времени появились?)
Про это вам ответил SergeyKish выше.
Полсекунды это разумеется общее понятие, по сравнению c Java и прочими бекендами, которые работают часами/днями/месяцами. Или же ваше «в сотни раз быстрее полсекунды» является универсальной оценкой для любой операции на любом PHP-сайте?
> В этом и есть разница, почему там PHP, а не Python/Ruby — в этой половине секунды.
Разницы никакой — Twitter(Rails) & Facebook(PHP) & YouTube(Python) работают одинаково быстро.
> (согласитесь, что разработчики этих сайтов не дураки, и раз написали производительные бэкенды и им всё равно пришлось переписывать фасад, то почему они снова выбрали пых, хотя вроде и более славные альтернативы к этому времени появились?)
Про это вам ответил SergeyKish выше.
habrahabr.ru/blogs/google/74948/ недавно тоже постил, но без перевода.
Слаще морковки ничего не пробовали?
> php
> справляется вполне достойно
> справляется вполне достойно
Немного разъяснений на тему «CPython vs. V8»:
[11/23/09 10:36:27 AM] Anatoly Kudinov: >Я не думаю, что возможно сделать реализацию CPython такой же быстрой как движки V8 или SquirrelFish Extreme, которые специально спроектированы для скорости.
сломал мозг, звучит как «я не думаю что можно сделать кефир таким же твердым как молоко» :)
Или питон действительно настолько медленней в арифметике или ещё чемто?
[11/23/09 10:45:28 AM] Ворушин: не питон, а его реализация CPython
[11/23/09 10:45:53 AM] Anatoly Kudinov: просто без ссылочек на бенчмарки непонятно насколько можно верить :)
[11/23/09 10:46:18 AM] Ворушин: это пишет разработчик Unladen Swallow, он точно в теме :)
[11/23/09 10:46:32 AM] Ворушин: Можно сделать такую же быструю реализацию, отойдя от CPython
[11/23/09 10:46:40 AM] Ворушин: К этому идет проект PyPy, например
[11/23/09 10:47:01 AM] Ворушин: А Unladen Swallow — ускорение CPython
[11/23/09 10:47:19 AM] Anatoly Kudinov: ага, понятно, спс )
[11/23/09 10:36:27 AM] Anatoly Kudinov: >Я не думаю, что возможно сделать реализацию CPython такой же быстрой как движки V8 или SquirrelFish Extreme, которые специально спроектированы для скорости.
сломал мозг, звучит как «я не думаю что можно сделать кефир таким же твердым как молоко» :)
Или питон действительно настолько медленней в арифметике или ещё чемто?
[11/23/09 10:45:28 AM] Ворушин: не питон, а его реализация CPython
[11/23/09 10:45:53 AM] Anatoly Kudinov: просто без ссылочек на бенчмарки непонятно насколько можно верить :)
[11/23/09 10:46:18 AM] Ворушин: это пишет разработчик Unladen Swallow, он точно в теме :)
[11/23/09 10:46:32 AM] Ворушин: Можно сделать такую же быструю реализацию, отойдя от CPython
[11/23/09 10:46:40 AM] Ворушин: К этому идет проект PyPy, например
[11/23/09 10:47:01 AM] Ворушин: А Unladen Swallow — ускорение CPython
[11/23/09 10:47:19 AM] Anatoly Kudinov: ага, понятно, спс )
Наверно с IronPython в этом смысле все несколько лучше. Правда гуглу от этого ясно дело ни холодно, ни жарко.
Интересно, о каких именно операциях и каких именно процентах ускорения идет речь. От этого зависит, насколько эта тема интересна за пределами задач масштаба гугла.
code.google.com/p/unladen-swallow/wiki/ProjectPlan
Goals
We want to make Python faster, but we also want to make it easy for large, well-established applications to switch to Unladen Swallow.
Produce a version of Python at least 5x faster than CPython.
Python application performance should be stable.
Maintain source-level compatibility with CPython applications.
Maintain source-level compatibility with CPython extension modules.
We do not want to maintain a Python implementation forever; we view our work as a branch, not a fork.
Goals
We want to make Python faster, but we also want to make it easy for large, well-established applications to switch to Unladen Swallow.
Produce a version of Python at least 5x faster than CPython.
Python application performance should be stable.
Maintain source-level compatibility with CPython applications.
Maintain source-level compatibility with CPython extension modules.
We do not want to maintain a Python implementation forever; we view our work as a branch, not a fork.
В этом я согласен и с гуглом и с твитером, удобство разработки хорошо, но продакшн сайта должен быть быстрым.
Есть же oberon, вот где скорость и простота, так ведь нет, питоны, джавы, пхп…
Гугловцы, прекращайте курить. Ваш Go намного медленнее CPython 3.1.
И вообще, tilarids.blogspot.com/2009/07/python.html ;)
И вообще, tilarids.blogspot.com/2009/07/python.html ;)
Sign up to leave a comment.
Python и скорость: Unladen Swallow, PyPy, Cython