Чтв 25 Янв 2007
За неимением в Интернете конкретной развернутой информации о сравнении скорости фреймворков, (я нашел только одно достаточно голое тестирование: Оно ограничивалось тремя фреймворками RubyOnRails, Django, Symfony и не содержало деталей), я провел детальный анализ для определения самого оптимального из шести ведущих по этим параметрам.
Update 04.Feb.2007: Pylons, RoR 1.2.1, CakePHP + eAccelerator, Zend, Turbogears with Cheetah, Jinja, Genshi
Итак, цель тестирования была - определение скорости работы самих фреймворков и сравнения их друг с другом по скорости генерирования страниц и максимальному количеству запросов на данной конфигурации.
Я выбрал тестовую модель, при которой контроллер рендерил определенный шаблон и генерировал ответ. В итоге получался HTML-файл c "Hello World!" (ниже есть код для каждого фреймворка). База данных в тесте не используется, так как она сама накладывает сильные ограничения на скорость.
Я не пытался сравнить функциональность фреймворков, коммьюнити, работу с базой данных. Мне важно было определить скорость работы именно движка MVC фреймворка, по возможности уменьшив влияние внешних факторов.
Поэтому я использовал связку Nginx + FCGI через IP:Port.
Были протестированы следующие фреймворки:
- CodeIgniter on PHP
- Catalyst on Perl
- Django on Python
- Django on Python with Psyco
- RubyOnRails on Ruby
- Symfony on PHP
- TurboGears on Python
CPU: AMD OpteronT Processor 146 (2 GHz) Memory: 2 GB OS: Debian 3.1 (Linux 2.6.14) Web-Server: nginx/0.5.5Версии фреймворков и языков программирования:
- CodeIgniter 1.5.1
- Catalyst 5.7006 Rev.5996
- Django Rev.4254 (28Dec.2006)
- RoR 1.1.6
- RoR 1.2.1
- Symfony 1.0beta2 SVN-Rev 3122
- Turbogears 1.0b3 Rev.2323
- Python 2.4.4
- Python Psyco 1.5.2
- Flup Rev.2303
- Ruby 1.8.5-p12
- mongrel 0.3.13.4
- PHP 5.2.0 (cgi-fcgi)
- perl, v5.8.4
- CPAN ver 1.8802
Siege 2.65 http://www.joedog.org/JoeDog/Siege Http_load 12.03.2006 http://www.acme.com/software/http_load/ ab 2.0.41-dev Rev: 1.141Методика тестирования:
- Измерение памяти (ps aux: VSZ "virtual set size" и RSS "resident set size").
- Тестирование ApacheBenchmark (2 раза подряд)
ab -c 5 -n 1000 http://project.com/
ab -c 100 -n 10000 http://project.com/
http_load -rate 10 -seconds 5 project.com
siege -d1 -t1M -c50 project.com
siege -d1 -t1M -c200 project.com
siege -d1 -t1M -c300 project.com
Для начала я прогнал один Nginx с простейшим конфигом, при котором на любой запрос выдается точечный прозрачный gif-файл размером 43 байта, генерируемый самим сервером.
Этим тестом была определена примерная максимальная пропускная способность самого сервера. Забегая вперед скажу, что запас его мощности в 10 раз больше пропускной способности самого быстрого фреймворка.
Все фреймворки запускались как FastCGI 127.0.0.1:PORT. Если фреймворком предусматриваются development и production режимы, то я работал с production.
В nginx использован одинаковый для всех конфиг.
Перезапуск фреймворка я проводил, чтобы очистить статистику между тестами разными программами.
Мои субъективные дополнения по каждому фреймворку при инсталляции и запуске:
- CodeIgniter
Легко ставится и быстро настраивается. Никаких проблем с ним не возникло. Для запуска использовал spawn-php.sh с пятью процессами.
Довольно шустрый для PHP фреймворк. - Catalyst
Для начала надо установить CPAN и парочку модулей для FCGI. Установка выглядела несколько запутанно.
Запуск также не простой. Для начала нужно запустить фреймворк./CatInABox/start.sh
Потом сам проект./script/world_fastcgi.pl -l 127.0.0.1:9500 -n 5
Код не так прост, но разобраться можно. - Django
Легко ставится из репозитария. Также легко создаются пректы. Запускал двумя методами prefork и threaded. Хотя питон не очень хорошо работает с тредами.
python manage.py runfcgi method=threaded host=127.0.0.1 port=8801 python manage.py runfcgi method=prefork host=127.0.0.1 port=8801
Также проверил фреймворк с модулем ускорения psyco. В manage.py вставил:from django.core.management import execute_manager import psyco psyco.full()
- RubyOnRails
Его легко поставить следуя инструкции с сайта, но оказалось сложно запустить. Хотя в интернете видел разные конфигурации для связки Nginx + FastCGI, мне не удалось запустить его вместе с nginx.
С lighttpd + FCGI же все запустилось нормально. Поэтому я воспользовался "официальной" рекомендацией запускать через сервер mongrel.
Благодаря Алексею Ковырину можно прикинуть коэффициент умножения.
Nginx+FastCGI быстрее примерно в 1.29 раз чем Nginx+Mongrel.
Запускал 5 серверов mongrel:mongrel_rails start -d -e production --port 8501 --pid /tmp/rb1.pid mongrel_rails start -d -e production --port 8502 --pid /tmp/rb2.pid mongrel_rails start -d -e production --port 8503 --pid /tmp/rb3.pid mongrel_rails start -d -e production --port 8504 --pid /tmp/rb4.pid mongrel_rails start -d -e production --port 8505 --pid /tmp/rb5.pid
Через пару дней после проведения тестов вышла новая версия RoR 1.2.1
Я, конечно, проверил и ее со всеми параметрами, обновил только фреймворк. Результаты несколько шокировали: падение производительности в 2 раза на всех тестах. - Symfony
Поставить было не сложно, но зато потом намучался с самим проектом. Довольно запутанно.
Для запуска использовал так же spawn-php.sh с пятью процессами. - TurboGears
При установке возникли небольшие проблемы, которые, немного повозившись, все же решил.
Для запуска в threaded режиме использовал скрипт отсюда, где изменилfrom fcgi import WSGIServer на from flup.server.fcgi import WSGIServer WSGIServer(application=wsgiApp).run() на WSGIServer(application=wsgiApp, bindAddress=
('127.0.0.1', 8900)).run()
Конфигурационные файлы web-сервера: Коды проектов каждого фреймворка: Скрипт запуска PHP-FCGI: Результаты web-сервера для сравнения: Результаты по каждому фреймворку в отдельности:
- CodeIgniter
- Catalyst
- Django prefork
- Django threaded
- Django prefork with Psyco
- Django threaded with Psyco
- RubyOnRails 1.1.6
- RubyOnRails 1.2.1
- Symfony
- TurboGears
- TurboGears with Psyco (не пошел, здесь вывод ошибки)
-
Тест ApacheBenchmark
- Таблица с скоростью обработки запросов
* 1) во второй раз фреймворк завис и не отвечал
* 2) коэффициент умножения по Ковырину =1.29. Для перевода скорости работы из mongrel в fastcgi
- Диаграмма со скоростью обработки запросов. Тест „ab c 5 n 1000“
- Диаграмма со скоростью обработки запросов. Тест „ab c 100 n 10000“
- Расход памяти до и после тестов
* 3) Питон устроен так, что при сильной нагрузке в режиме prefork он перестартует свои процессы. Поэтому невозможно определить реальную загрузку процесора и максимальное потребление памяти.
- VSZ "virtual set size"
- RSS "resident set size"
- Загрузка процессора
- Таблица с скоростью обработки запросов
- Тест http_load
- Siege тест
Выводы:
Результаты видны по таблицам и графикам.
Некоторые дополнения:
Меньше всего потребление процессора у django.
Удивил Catalyst, который при чрезмерной нагрузке резко начинает грузить процессор. Хотя потерь запросов не наблюдалось.
RoR 1.2.1 под большой нагрузкой также сильно грузит процессор.
Интересно было у TurboGears, который показал низкое потребление времени CPU в тесте "ab", но зато в siege-тесте имел самый худший результат.
Потребление памяти самым большим оказалось у Catalyst, у RoR оно скорее обусловлено запуском через mongrel.
PHP-фреймворки даже в спокойном состоянии занимают много ресурсов CPU.
Среднее время коннекта для всех примерна равно. Время первого отклика сильно отличается, отличился django, имея наименьшее среднее время и самое высокое максимальное время коннекта. Фреймворки на питоне показали себя с хорошей стороны, а вот руби разочаровал.
Во время siege-теста наблюдались потери при большом количестве "concurrent users" у CodeIgniter, Symfony, RoR 1.2.1 & 1.1.6
Руби быстр при небольшой нагрузке, но резко теряет производительность при большом количестве пользователей.
Psyco модуль ускоряет django на 15-30%, но за это приходится расплачиваться возросшим потреблением памяти VSZ на 80% в prefork-режиме и на 400% (!!!) в threaded-режиме. RSS потребление увеличивается в 2-2.5 раза.
Prefork-режим забирает больше памяти, но за это получается система, стабильно работающая на больших загрузках, и меньшее потребление ресурсов процессора.
В threaded-режиме django зависал под большой нагрузкой и не отвечал на запросы.
Это же происходило и с TurboGears. Связано это с плохой работой питона в threaded-режиме.
Комментарии от Ивана Сагалаева:
Да, система 32 битная."- FastCGI сервер запущен в threaded-режиме. Известно, что Питон в тредах работает существенно медленно из-за GIL (Global Interpreter Lock), из-за которого все треды очень часто просто ждут друг-друга, потому что интерпретатором может владеть только кто-то один. Поэтому в юниксах, если есть возможность, серверы с питоновским кодом стоит запускать в prefork-режиме - будет быстрее. Кстати, под Windows ситуация обратная, потому что там создание процесса существенно медленней, чем в юниксах, и там на тредах Питон тормозит, насколько я знаю, все же меньше. - Насчет Psyco. Джанговские девелоперы тестировали его, и нашли интересную штуку. На 32-битных системах он действительно дает прирост в производительности. А вот на 64-битных - наоборот, производительность падает. Происходит так из-за того, что под Psyco процессор переключается в 32-битный режим и не использует всех прелестей своей архитектуры. Если все это так, то тот факт, что под Psyco Django таки работал быстрее означает, вероятно, что Linux и Python скомпилены не в 64 битах (несмотря на то, что работает это все на Opteron'е). Это так?"
Распределение мест по данному тесту:
- Минимум с трехкратным превосходством над ближайшими конкурентами победил django.
- Второе и третье места поделили TurboGears и RoR 1.1.6, так как они одинаково быстры, но ведут себя по разному при разных нагрузках, обгоняя друг друга.
- .
- Catalyst. Честно говоря, от фреймворка на перле я ожидал большего.
- CodeIgniter. Фреймворки на PHP, как и ожидалось, оказались самыми медленными. Но CodeIgniter можно посоветовать тем, кто хочет программировать только на PHP, и в тоже время иметь удобную и относительно быструю систему.
- Результаты RoR 1.2.1 сильно шокировали: падение производительности в 2-4 раза по сравнению с 1.1.6 версией.
Время первого отклика в http_load также больше в 2 раза, чрезмерно высокое потребление процессорного времени при высокой нагрузке, все это скорее говорит о какой-то ошибке в новой версии. - Symfony досталось последнее место. Очень сложный и медленный фреймворк. Разница с django - до 35(!!!) раз.
P.S. По многочисленным просьбам (так как я использовал для django ускоритель Psyco) сделал сокращенный тест для фреймворка на PHP с ускорителем eAccelerator-0.9.5.
Использовал команды, запущенные два раза подряд:
ab -c 5 -n 1000 http://ci.test.com/ ab -c 100 -n 10000 http://ci.test.com/В результате CodeIgniter заработал в 6,5 раз быстрее, выдавая до 600 запросов/сек.
В сравнении с django разница сократилась до двух раз.
Здесь эти результаты
Январь 29th, 2007 at 11:27 д.п.
1. А почему не учли тот факт, что php по большей части ставится и используется как модуль апача и в таком случае он работает быстрее?
2. Жаль, что в тестировании не участвовал CakePHP (cakephp.org).
Январь 29th, 2007 at 11:49 д.п.
Для Pento:
PHP в FastCGI-режиме + nginx работает производительнее, чем Apache + mod_php.
Вопрос к автору: PHP был с ускорителем/кешем или без?
Январь 29th, 2007 at 11:57 д.п.
Отличный тест, спасибо за проделанную работу.
Хотел бы заметить, что в больших боевых проектах php редко используется без всяческих memcached'ов, zend optimizer'ов и прочих. Этот фактор сильно влияет на производительность. Странно, что про это в статье нет ни слова, а вот про питоновский psyco не забыли, ага.
Январь 29th, 2007 at 1:19 п.п.
У Вас в perl, простите, хрень какая-то в отчёте.
Запрашиваете один документ (/), а получаете - совсем, совсем другой (/hello/). Значит, для одного фреймворка тестировали ещё и редиректы в нагрузку.
Разброс min и max time для запросов косвенно указывает на то, что какие-то модули могли докомпиляться после рестарта фреймворка. Почему не делали "пустой" прогон теста, чтобы всё что нужно было уже откомпилированным в памяти перед основным запуском?.
Что тестировали, собственно, тоже не понятно: делаются ли проверки ACL при доступе к ресурсам? Как ведут себя встроенные template движки (вы же их используете) на больших страницах с малым количеством динамики, на больших страницах с больших количеством динамики?
Январь 29th, 2007 at 1:47 п.п.
Жаль, что Zope никак не учавстовал.
Январь 29th, 2007 at 2:02 п.п.
2 Pento: Про апач BOLK уже ответил, а на CakePHP можно взглянуть...
2 BOLK, zhulanov: PHP был без ускорителя и без кеша. я старался снизить посторонние влияния, то что psyco протестировал, так это для сравнения с самом django. Конечно и зенд и кеш сильно ускорят работу. Но это уже связки.
2 thenexus6: Спасибо, исправил. реально тестировал с прямым линком http://ct.test.com/hello/
Про подгрузку подулей в перле не подумал. Мой косяк. В других тестах прогонял по 2-3 раза, а http_load сделал один раз.
>>Как ведут себя встроенные template движки (вы же их
>>используете) на больших страницах с малым количеством
>>динамики, на больших страницах с больших количеством
>>динамики?
цель тестирования была одна маленькая страничка. и маленькая динамика.
Конечно можно тестировать все фреймворки со всеми ускорителями/без них, с проверкой ACL и без нее, с кучей динамики и не очень. с кучей темплейтов и с одним. еще кучу режимов для всех тестовых программ использовать.
Но этот тест дает только общее представление о производительности фреймворков. А вот конкретный проект каждый должен сам тестировать, и находить подходящий для него вариант.
Январь 29th, 2007 at 2:18 п.п.
Когда я у себя тестировал Ruby on Rails, то он действительно просаживался, будучи запущенным через mongrel.
Однако запущенный через lighttpd + fastcgi (модуль ruby-fcgi native, не pure ruby режиме) (команда запуска: script/server lighttpd) он не только показывал большую производительность (35 страниц/сек вместо максимального 29 через mongrel), но и не проседал - т.е. даже под 200 пользователями показывал те же 35 страниц в секунду.
Январь 29th, 2007 at 2:23 п.п.
Кретив - газетный, автор - метролог...
Писькомерка с погрешностями. Ведущие - это по чьему мнению? По мнению автора?
А где Zope питоновский?
Где CakePHP? Почему выбрали среди PHP фреймворков одну из самых медленных?
И если уже ROR юзали на Mongrel в родных условия, могли бы PHP в mod_php проверить. :(
Январь 29th, 2007 at 2:24 п.п.
И php обязательно нужно с ускорителем (тот же eAccelerator).
Ибо:
1. в python, ruby, perl компиляция кода фреймворка происходит лишь один раз, а в php без акселератора - каждый.
2. ни один нагруженный сайт на php не идет без акселератора
3. (как следствие) ни один хостер не запускает php без акселератора.
Т.е. сравнивать с php без акселератора не честно
Январь 29th, 2007 at 6:06 п.п.
Бред. Еще один синтетический тест не имеющий отношения к реальности.
Январь 29th, 2007 at 6:15 п.п.
Еще бы с БД тесты увязаны были
Например отобразить 50 строк из одной и той же таблицы
А то есть подозрение что работа с БД в джанге любимой тормозид )
Январь 29th, 2007 at 6:42 п.п.
Sorry, was ist mit Cake? Soviel ich weiß, codeigniter ist kein bestes unter PHP frameworks...oder?
Январь 29th, 2007 at 6:53 п.п.
To thenexus6, Alexandr Kot, savagex Ну вы блин даете, нытики несчастные! Чел потратил время – работа не малая, тест познавательный. Обнародовал, так сказать для нужд всеобщих, умные возьмут что-то для себя.
Аффтар респект, не слушай никого, всегда найдутся, которые обсирают всех и все без разбора, и без реального понятия и объяснить то не могут: «Ведущие - это по чьему мнению?» ну напиши свое мнение. А его нет, они просто ходят по блогам и в коменты срут, где придется.
«Бред. Еще один синтетический тест не имеющий отношения к реальности.»
ты сам бред несешь, он о кирпиче, а ты о яйцах, ясно же написано – это только ориентиры, направление,а для каждого проекта все очень индивидуально.
Найми пару работничков, поработайте пару месяцев бесплатно и сделай себе «несинтетический тест, имеющий отношение к реальности»
Январь 29th, 2007 at 7:27 п.п.
Почему не Python-2.5? И где CakePHP?
Январь 29th, 2007 at 9:45 п.п.
> Psyco модуль ускоряет django на 15-30%, но за это приходится расплачиваться возросшим потреблением памяти VSZ на 80% в prefork-режиме и на 400% (!!!) в threaded-режиме.
Дело всё в том, что использовался psyco.full(), а если делать хорошо, то по идее надо профайлером посмотреть, где именно тормозит, и отдавать на ускорение только части. Ну да это очень долго, и заниматься таким стоит только от безысходности :)
Январь 29th, 2007 at 10:01 п.п.
Rails' development mode = slow. Doh. It reloads the entire application on every request.
Try again: `mongrel_rails start -e production`.
Январь 29th, 2007 at 10:18 п.п.
Great work! Thanks for your efforts.
And the django-searchengine was very opportunely ;)
Январь 29th, 2007 at 11:03 п.п.
Работаю с RoR давно, и связка mongrel + Apache mod_proxy_ballancer работает очень шустро.
Январь 29th, 2007 at 11:34 п.п.
Ответ от читателя:
PHP был с ускорителем/кешем или без? - это до лампочки в контексте разов.
Январь 29th, 2007 at 11:37 п.п.
Жаль, что не протестировали какую-нибудь отечественную разработку, например, Cairo (http://www.cairo.com.ua)
Январь 30th, 2007 at 12:31 д.п.
2 Mark: Du bist nicht der einzige, der fragt :-) Ich mach’s im nächst. Wollte heute schon, es hat aber nicht geklappt mit Cake schnell zur Recht zu kommen
Январь 30th, 2007 at 12:33 д.п.
2 Boo
Попробую этот фреймворк в ближайшее свободное время. Хотел сегодня еще сделать, установил, запустил, но не получилось быстро разобраться с проектом.
Январь 30th, 2007 at 12:35 д.п.
2 Jules:
Thanks, it’s a misprint, I have really used production, already corrected :-)
Январь 30th, 2007 at 1:55 д.п.
2 framexpert:
Каиро - это CMS, а я тестировал только CMF, причем только современные MVC
Январь 30th, 2007 at 9:26 д.п.
Работа большая и полезная. Хотелось бы, чтобы автор повторил тесты (через некоторое время) с учётом высказанных замечаний и предложений.
Январь 30th, 2007 at 2:41 п.п.
Hello,
this comparison is really a great idea and well done, thank you.
Just to increase the comparison completeness, above all if a Python developer wants to choose between one of the two choices on his side: could tou please add the Turbogears performance serving a page generated with CheetahTemplate instead of TAL?
Many would prefer Cheetah over TAL simply because they don't want to write XML template; an hint about the implication of this choice on the performance would be great.
Thank you again ;)
Январь 30th, 2007 at 4:58 п.п.
This is completely unscientific! Running a PHP bytecode cache will improve the performance of PHP frameworks 10 fold! It's not surprising that they're slow with zero optimisation.
Январь 30th, 2007 at 7:41 п.п.
It will be interested to see test of an java MVC framework also. For example http://struts.apache.org/ on http://tomcat.apache.org/
Thanks.
Январь 31st, 2007 at 12:59 п.п.
thanks
Январь 31st, 2007 at 6:32 п.п.
PHP specific: using byte code cache.
Server Software: Apache
Server Hostname: ******
Server Port: 80
Document Path: /myproject/web/mymodule/myAction
Document Length: 986 bytes
Concurrency Level: 100
Time taken for tests: 11.709703 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 1361360 bytes
HTML transferred: 986986 bytes
Requests per second: 85.40 [#/sec] (mean)
Time per request: 1170.970 [ms] (mean)
Time per request: 11.710 [ms] (mean, across all concurrent requests)
Transfer rate: 113.50 [Kbytes/sec] received
apache2.2/php 5.1.6/eaccelerator
AMD Athlon(tm) 64 Processor 2 Gz
RAM: 1 Gb DDR400
OS: Gentoo Linux 2006.1
webserver: Apache (mpm-event (threaded))
Январь 31st, 2007 at 7:56 п.п.
I’ll try to take into account all wishes and to post additional results as fast as possible
Январь 31st, 2007 at 8:40 п.п.
Ouch! It's hard to be a Rails developer who's so invested in the framework and see results like that. Hopefully they'll clean up whatever they did in the 1.2.1 branch that made it 4x (!) slower.
Январь 31st, 2007 at 11:32 п.п.
This is only results for THIS SMALL project "Hello World" ;)
The test is only like a direction.
Февраль 1st, 2007 at 10:42 д.п.
> 1. в python, ruby, perl компиляция кода фреймворка происходит лишь один раз, а в php без акселератора - каждый.
такое может быть только в cgi режиме, через fastcgi или mod_php - все скрипты висят в памяти постоянно.
акселлератор тут не причем. ..насчет хостеров - у них его точно не стоит т.к. он не понимает свежих версий php и вообще не любой код может через него работать.
что касается memcached - причем тут php? Его использовать можно из любых языков, но это отдельная история и в тесте неуместная совершенно.
> Бред. Еще один синтетический тест не имеющий отношения к реальности.
+1. тест абсолютно не о чем, разве что - иллюстрация неправильной установки этих самых фрейморков. более того, он вреден т.к. кто-то это может серьезно воспринять.
"Мне важно было определить скорость работы именно движка MVC фреймворка" - забавная тема для теста, но следовало бы написать большими буквами, что к реальным приложениям он отношения не имеет т.к. многие читатели этого не осознают.
Почему nginx? Патриотизм? ligthttpd был бы более уместен..
Почему fastcgi через tcp, а не через сокет?
Psyco работает только на x86..
"питон не очень хорошо работает с тредами." - lol
Февраль 1st, 2007 at 11:24 п.п.
>когда не получается меряться удобством и практичностью, меряются скоростью
Кому нужна практичность и удобство при кривом коде и ужасной производительности ? Я до тошноты нагляделся на красивые и удобные PHP проекты, которые жрут по 20 Мб памяти и делают по 100 запросов к MySQL на каждое обращение к странице.
Февраль 1st, 2007 at 11:25 п.п.
> остальные фреймворки компилят свой код лишь однажды, php без акселератора - на каждый запрос
как это кривье написали, так и сравнивают. все честно.
Февраль 1st, 2007 at 11:25 п.п.
а помоему, руби - более интересный язык, чем питон.Учитывая несильное отставание в производительности я бы выбрал более интересный инструментарий.
Хотя, конечно, этот фактор не определяющий в данном вопросе. (и субъективный)
Февраль 1st, 2007 at 11:26 п.п.
what about Zope? а что про zope автор скажет?
>>>
django - как самый удобный, практичный и, как оказалось, самый скоростной
<<<
хотелось бы услышать сравнение и по Zope, особенно в плане практичный и удобный...
Февраль 1st, 2007 at 11:27 п.п.
Zope - страшный тормоз. Говорю как человек писавший и под чистый зоп и под plone.
Февраль 1st, 2007 at 11:28 п.п.
Респект за подробное тестирование без marketing shit. За PHP обидно, какой то он ну уж очень тормозной получился... сам сейчас на 5ке пишу, заставил задуматься... С другой стороны памяти мало потребляет, в апачь модулем встраивается, этим обусловлен успех и любовь среди хостеров вероятно...
Впрочем питон сейчас тоже mod_python'ом у многих хостеров стоит, со следующего проекта подумаю перейти на него.
Февраль 1st, 2007 at 11:29 п.п.
А по-моему всё это тестирование сплошной marketing shit. RoR позиционирует себя прежде всего как платформу для быстрой разработки, но не для быстрой работы. Это всё равно что сравнивать "кто быстрее довезёт килограмм яблок из Москвы в Питер? Камаз или Ferrari" Довозит быстрее Ferrari, но ведь Камаз и не пытался за ней угнаться.
Кстати, тема озаглавлена "Почему RoR-1.2.1 так глючит?", но никакого описания "таких" глюков я тут не вижу.
И ещё, в самом начале статьи указаны три требования к платформе которые мне кажутся уж если не противоречащими, то соперничающими.
Февраль 1st, 2007 at 11:29 п.п.
Вопрос нужно поставить так: почему RoR v.1.2.1 работает в два раза медленнее, чем v.1.1.6? Только бросать его нужно в maillist RoRа, а не сюда.
На этот тест человек потратил немало времени. Нужно спасибо сказать. Может, отправить ему письмо, в котором написать, что он делал не так? Или самому провести тест?
Тест проведён действительно неплохо, есть общие замечания, все они высказаны в комментариях по ссылке. Выскажите свои, никто не запрещает.
Он никогда скоростью не отличался. Он берёт другим. Дешевизной рабочей силы.
Февраль 1st, 2007 at 11:30 п.п.
Несмотря на то, что это приятно, все же надо помнить, что это только URL маппер и шаблоны. То есть для реальных приложений будет другая статистика. Все равно, конечно, Django быстрее, но не настолько.
Февраль 1st, 2007 at 11:31 п.п.
Было бы интересно также замерить насколько Django становится медленней относительно "hello world". Таким образом, HW это будет универсальная единица производительности и можно будет смотреть насколько падает в HW производительность при увеличении сложности задачи в разных фреймворках. Даже графики сравнительного измнения HW в зависимости от типа задачи можно строить.
Потом жаль, что забыли про java. По легенде java быстрее питона в несколько раз и было бы интересно посмотреть на Tomcat+Struts или +Spring MVC.
Февраль 1st, 2007 at 11:32 п.п.
сделал небольшой тест - рабочее приложение, добавил контроллер,
отключил AuthenticatedSystem, но все плагины остались.
ab -n 20 http://localhost:3000/test
Requests per second: 22.07 [#/sec] (mean)
после добавления session :off
Requests per second: 60.95 [#/sec] (mean)
Февраль 1st, 2007 at 11:33 п.п.
> а ты уверен что цепляются новые
> рельсы а не старый гем? это зависит от
> boot.rb
environment.rb, там ведь версия рельс
прописывается.
Но лучше все таки стереть старые
версии.
Февраль 1st, 2007 at 11:34 п.п.
ты прав, проверил и там была прописана старая версия.
только существенно она ничего не изменила. я провел дополнительно
тест, при этом удалив из gems 1.1.6
Скорость возросла в полтора раза, но все же существенно меньше, чем у
1.1.6 , до двух раз.
Полные результаты выложу на выходные
Февраль 1st, 2007 at 11:35 п.п.
Обновил свои приложения до версии 1.2.1
Посыпались ошибки. Application Error. В логах Production:
ActionView::TemplateError (undefined method `image2_relative_path' for
#<Car:0x41910b2c>) on line #23 of app/views/cars/show.rhtml:
20: <% end%>
21: </td>
22: <td><% if @car.image2? %>
23: <a href="<%=url_for_file_column(@car, "image2",
"medium")%>" class="thickbox" rel="gallery-plants" ><%= image_tag
url_for_file_column(@car, "image2", "thumb") %></a>
24: <% end%></td>
25: </tr>
26:
/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/
base.rb:1792:in `method_missing'
#{RAILS_ROOT}/vendor/plugins/trunk/lib/file_column_helper.rb:75:in
`send'
#{RAILS_ROOT}/vendor/plugins/trunk/lib/file_column_helper.rb:75:in
`url_for_file_column'
Возвращаю на сервер БэкАп - версию 1.1.6 - Не работает.
Пусть заработает хотя бы 1.1.6. Помогите .
Февраль 1st, 2007 at 11:35 п.п.
You have compared a bunch of high level web development frameworks,
whose express purpose is to make development of complex web
applications simple, by comparing their most basic performance metrics
as if they were HTTP servers.
This is the kind of information that would be useful to the people
actually developing the frameworks, they might have ended up with some
kind of scary latency hidden somewhere, but to anyone else the
information is misleading in the extreme.
The problem is that at this level of framework, the speed of the final
site is a combination of 3 things: The speed of each involved
component of the framework (Turbogears has half a dozen, of which you
barely tested 2, cherrypy and kid), the speed and nature of the
supporting platform (windows? linux? fast disks? lots of cache?), and
the supporting optimisations (indexes on tables, memcached, load
balancing and pre-caching etc)
Hence someone unfamiliar with any of the frameworks, determined to
learn one, may be misled by your metrics into believing they should
choose one or another on the basis of "speed" when in fact the numbers
you have measured are a tiny fraction of that required to make any
real statement on the "speed" of a framework, even if you take the
reasonable course of ignoring local optimisation.
Added to that is the odd choice of forcing FCGI on everyone. You'd
have been better to simply deal with the frameworks however they like
to work natively, that's where they perform best. I always deploy
Turbogears with cherrypy proxied via apache for example.
I think you would do better to point out to readers on your blog that
they should not be making framework choices based on this kind of
speed metric as a primary decision maker. If everything else is a tie
(right language, right platform, experience to hand, fit with current
environment, fit with developer minset etc) then sure, but looking at
the charts and going straight for django on the basis that it was
"fast", or dismissing Symfony because it's "slow" is as good as
rolling a dice from a project perspective.
Nobody in a performance-critical environment will ever deliver static
content through the templating system or the application server, so
these numbers will never come to light in practice.
Февраль 1st, 2007 at 11:36 п.п.
Nor does it make any sense to compare hit times using the default
templates when
a) changing template engines is easy and will vastly change that stat
b) the purpose of the various template engines is quite different as
regards the high level programming vs speed equation, with kid and
genshi being xml parsed and django and cheetah being text templates
Февраль 9th, 2007 at 7:11 п.п.
What a pity! You have choose a very wrong framework. CodeIgniter is level 2 framework and Symfony is something like plain old Mojavi with almost design and not-optimal code.
If you want to choose a speedier and more elegant framework, have a look at http://www.paul-m-jones.com/blog/ : Zend (http://framework.zend.com), CakePHP (http://cakephp.com), Solar (http://solarphp.com) may be better
Февраль 10th, 2007 at 5:54 п.п.
This is a great comparison. Thank you very much !
Март 18th, 2007 at 5:46 п.п.
Респект и уважуха за работу.
Март 23rd, 2007 at 1:35 д.п.
I think your tests are misleading, and that Richard Clark's comments are spot on. You need to look at a wide range of things and not just a hello world app to get a good idea of each framework's strengths and weaknesses. For example, Catalyst takes a big hit up front, but that's because it will deal with complex dispatch logic well ahead of ?most? of the other frameworks without degrading too badly.
Август 14th, 2007 at 3:15 д.п.
Ein interessanter Vergleich. Es wäre sehr toll, dieses Experiment auszuweiten und auf andere Frameworks sowie Content Management Systeme anzuwenden, unter Einbeziehung aller weiteren Elemente zur Optimierung (Datenbankabfragen, Compilierung, caching-Mechanismen, etc.). Auch ein Vergleich mit der Ladezeit eines hallo _welt.html wäre interessant. Und, wie lange dauert ein pdf, etc. ... und die Druckgeschwindigkeit ;-)
Gruß, Nils
Сентябрь 12th, 2007 at 10:34 д.п.
I am really fine with this benchmark job. Congratulations.
Сентябрь 21st, 2007 at 8:04 п.п.
These comparisons are on the basis of performance. Yes, which is one of the most important aspect in multi-user environment. As we recently studied Symfony, which is worst (according to the current article), but it may be the best, if a company is client based, and it has to develop sites for client (some of other framework yet to be explored). In that particular scenario, Symfony is good, as maintenance of the site after development becomes very easy.
But at the another side, If we are working in multi-user environment with high concurrency, this hits the bottom line. However, we can use lot of optimization at sever as well as script (eg. php) level, as to solve the problem before reaching a specific threshold. Yes, there should always be a good extraction from the available resources (hardware, software & human). So a developer should choose the best available option which suits his/her requirements.
regards,
Vishnu
naukri.com
Октябрь 7th, 2007 at 6:59 п.п.
Скоро выйдут рельсы 2.0, очень хотелось бы сравнение их с джангой.
Октябрь 9th, 2007 at 10:19 д.п.
Спасибо! Давай еще! Я новичек и для меня это просто склад информации. Теперь реализовывая какой-либо проект буду смотреть со всех сторон...
Продолжай. Народ просит.
Октябрь 14th, 2007 at 11:08 п.п.
RoR's ram consumption is through the roof. Those mongrel procs + apache procs suck up tons more RAM than even php. This is going to get expensive if you need to roll out a load balanced cluster. Scaling matters despite all the hype that hardware is faster and cheaper. It's not the only factor, but it's definitely one not to dismiss.
Python is probably the best scaling scripting language out there, and Django makes it as fast/easy to deploy as php or RoR.
Testing php without eaccelerator or apc installed is completely unfair. It takes 10 minutes to compile and configure and there is literally no drawback to it. Php6 will come with APC baked in.
I've used php with Cake & Symfony. I've used RoR. I've used python but never with a framework. If someone asked me what to learn today, I'd tell them python for it's quality and php for it's job opportunities. The RoR community freaks me out like the spanish inquisition. They talk the talk, but what high traffic sites are running RoR? None to my knowledge. Meanwhile Google is running a lot on python, and php, despite all the constant criticism and bashing, probably runs more famous websites than anything else...
Ноябрь 13th, 2007 at 9:31 п.п.
@noel: Yep, no big traffic sites running RoR. Oh... except ummm Twitter, Basecamp, etc. Twitter alone is getting something in the range of 14,000 reqs/sec.
Декабрь 8th, 2007 at 9:36 п.п.
Now if we could just test this against some Java site, it would be interesting. Yes I know Java is a political decision these days but just curious.
Декабрь 15th, 2007 at 3:52 д.п.
I still think CakePHP is easiest to use, but thats just me...... must have taken a while to conduct these studies.
Декабрь 17th, 2007 at 5:43 п.п.
@chrisdpratt
http://www.radicalbehavior.com/5-ques...
Read bullet point 2.
Rails is a decent framework, sure, but people who aren't followers of the Rails cult tend to be more realistic. So, Rails can scale if you have a server farm to throw at it. Big deal. What I am interested in is frameworks that are not so wasteful and put more effort into development than marketing and hype.
Simply put, Rails is ok, but there are far better options available. They just don't have hordes of starry-eyed fans screaming and fainting over them.
Январь 22nd, 2008 at 2:30 п.п.
Good , very good SITE !!! THANK YOU FOR THIS site!!
Nice job!Can I put you link on my site?
Февраль 7th, 2008 at 9:18 д.п.
Thanks for this comparison. I stumbled upon it while looking for something else
Most of us can appreciate that you put a lot of time into this.
its a shame theres so many comments here from know it all knit picking idiots ..... All tests can be subjective depending on the context in which they were tested for....
I for one would never have the time to do such tests myself so thanks again for making this available for the rest of us!
Май 27th, 2008 at 7:11 п.п.
That is so pointless it really hurts.
All i see is a test of serverconfigs with some languages.
I don't care what language (added with same arbitary framework overhead) performs best with Nginx+FastCGI and 5 processes.
Июль 2nd, 2008 at 12:25 д.п.
you compared a byte code compiled, jit'd python environment to a straight interpreted PHP one. in order for this to mean *anything* at all you really need to add APC into the PHP loop.
Июль 11th, 2008 at 8:06 д.п.
Gr8 work. Can u suggest me how to use psycho in web apps with python
Июль 11th, 2008 at 1:21 п.п.
2sammypy:
just add in manage.py
import psyco
psyco.full()
But it doesn't work with Django from SVN.
See http://code.djangoproject.com/ticket/...
See also too (other solutions)
http://code.djangoproject.com/wiki/Ps...
http://www.artfulcode.net/articles/ps...
Август 7th, 2008 at 7:11 д.п.
Yeah it's a shame that RoR is so slower than others. I don't recommend it to friends that want a scalable web site :)
And yet I use it all day.
You may want to use evented mongrel to test your RoR deployments. It is known to work better under heavy loads.
There is also a hope that with asynchronous DB access and Ruby 1.9 and thread-safe rails that RoR speed will increase. We'll have to see. Until then... :)
-R
Декабрь 4th, 2008 at 9:15 п.п.
Приветствую.
Уже давно, и несколько раз, просматривал ваше сравнение.
Можно сказать, одно из самых информативных и полезных, спасибо вам.
Не думали ли вы актуализировать тестирование? Как ни как, почти два года пришло. А тема все еще волнует умы людей ;-)
Заранее спасибо.
Февраль 23rd, 2009 at 6:43 п.п.
>2. Жаль, что в тестировании не участвовал CakePHP (http://cakephp.org).
кейк вообще тормоз :(
как насчет теста yii ?
Февраль 28th, 2009 at 1:33 п.п.
I agree, that many framework developers are not aware of performance issues. A reason for that may be the availibility of byte code caching or other tools to store information (e.g. application caching, memcached, …). But this is not true for everyone. Especially, the APF is designed for best performance (see http://adventure-php-framework.org/Pa...). Combined with a rich featureset (see http://adventure-php-framework.org/Pa...), the APF is worth a try!
Апрель 29th, 2009 at 8:10 п.п.
Better than APF is eAccelerator. PHP with eAccelerator would be close to preforked Django in these tests (we've run our own tests similar to these and confirmed).
Июнь 6th, 2009 at 10:22 д.п.
Basically, "APF" has nothing to do with "eAccelerator". If you want to clearly compare two frameworks like Django and the APF you have to do four runs:
- APF without eA
- Django without eA
- APF with eA
- Django with eA
After that you can assign two values:
- The plain performance of the tested framework
- The degree of optimization, eA can add to the framework's code.
I would be glad, if you could post these values here.
Ноябрь 23rd, 2009 at 5:19 д.п.
Can you test KumbiaPHP[1] Framework in next Benchmark?
Here you have a Benchmark KumbiaPHP, is very fast ;-)
[1] http://www.kumbiaphp.com
[2] http://wiki.kumbiaphp.com/Frameworks_...
Март 10th, 2010 at 7:19 д.п.
MVC Catalyst + Moose = The best
Апрель 6th, 2010 at 7:09 п.п.
I made a bit of post on PHP MVC Frameworks in general, might be of interest... http://www.sheldmandu.com/php/php-mvc...
Май 16th, 2010 at 2:30 п.п.
This is 3-year old now, any update on this?
Июнь 10th, 2010 at 6:43 п.п.
It's time for Python framework vs Java framework.
Let's get it on!
Октябрь 12th, 2010 at 8:28 п.п.
Жалко, что я пост прочитал уже через пару месяцев как персел на django. Нужно было раньше бросить ковыряние в php. А сейчас приходится все проекты переность, т.к. сервак под CakePHP реально проседает, хотя CakePHP считается более шустрым, чем CI.
Октябрь 15th, 2010 at 12:26 п.п.
PHP без акселератора? Неравноценные условия с питоном, т.к. в последнем оптимизация встроена в интерпретатор, а в PHP аналогичные действия просто вынесены наружу — на откуп стороннему п/о. Но без акселераторов в продакшене PHP никто не использует, поэтому получился синтетический тест интерпретаторов языка, а не фреймворков.
Февраль 19th, 2011 at 3:28 п.п.
Да, хотелось бы полноценные тесты для PHP CodeIgniter+eAccelerator.. А то за родину абидна=)