Do 25 Jan 2007
The performance test of 6 leading frameworks
Posted by Alrond | Tags: Catalyst : CodeIgniter : Django : framework : Performance test : php : Ruby on Rails : Symfony : TurboGears :
For absence of the concrete developed information about speed comparison of frameworks in the Internet, (I have found only one testing, but it turned out naked enough. It was limited to three frameworks RubyOnRails, Django, Symfony and didn’t contain absolutely any detail), I conducted the detail analysis for decision of the 6 best frameworks in all these parameters.
Update 04.Feb.2007: Pylons, RoR 1.2.1, CakePHP + eAccelerator, Zend, Turbogears with Cheetah, Jinja, Genshi
So, the purpose of testing was the decision of work speed of frameworks and their comparisons with each other on speed of pages generating and on maximum quantity of inquiries by the given configuration.
I have chosen the test model, at which the controller rendered the appointed template and generated the answer. As a result turned out the HTML-file "Hello World!" (below there are codes for everyone framework). The Database in the test is not used, because it itself limits the speed important.
I did not plan to compare functionality of frameworks, community and work with database. It was important to me to determine work speed of MVC-framework, by as small as possible influence of external factors.
Therefore I used sheaf Nginx + FCGI through IP:Port
The following frameworks have been tested:
- 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.5Versions of frameworks and programming languages:
- 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.141Technique of testing:
- Measurement of memory (ps aux: VSZ "virtual set size" and RSS "resident set size").
- Testing Apache Benchmark (2 times in succession)
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
For the beginning I have used only Nginx with the elementary config, at which on any inquiry the dot transparent gif-file in the 43b size comes, generated by a server.
This test determined an approximate maximal capacity of the server. In front I shall tell that a stock of its capacity is 10 times more then production capacity of the fastest framework.
All frameworks were started as FastCGI 127.0.0.1:PORT. If framework specified development- and production- modes, I worked with production.
In nginx the identical config is used for all frameworks.
New start of framework I conducted to clear statistics among tests different programs.
My subjective additions on every framework by installation and start:
- CodeIgniter
It is easy and quick to organize it. I haven’t any problems with it. For start I used spawn-php.sh with five processes.
There is pretty bright framework for PHP. - Catalyst
For the beginning it is necessary to install CPAN and a couple of modules for FCGI. Installation looked a little involved.
Start isn’t simple too. For the beginning it is necessary to start Framework./CatInABox/start.sh
Then the project itself./script/world_fastcgi.pl -l 127.0.0.1:9500 -n 5
- Django
It is easy to install from repository. Projects are created easy too. I started with two methods prefork and threaded. But the python doesn’t work so well with treads.
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
I also tested the framework with the acceleration module of psyco. In manage.py put:from django.core.management import execute_manager import psyco psyco.full()
- RubyOnRails
Following the instruction from a site it is easy to install, but it turned out difficult to start it. Though on the Internet I saw different configurations for sheaf Nginx + FastCGI, I failed to start it together with nginx.
However with lighttpd it all started normally. Therefore I have taken advantage of the "official" recommendation to start it through a server mongrel.
Owing to Alexey Kovyrin it is possible to estimate a multiplication factor.
Nginx+FastCGI is faster approximately in 1.29 times than Nginx + Mongrel.
I started 5 servers 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
In a few days after test realization a new version RoR 1.2.1 came out.
Of course I has also tested it with all parameters, has only renewed framework, checked all specifications. Results are shocking a little: factor productivity halved in comparison with previous version in all tests! - Symfony
It wasn’t complicated to install it, but then was worn out with the project itself. There is difficult enough. For start I also used spawn-php.sh with five processes. - TurboGears
By installation were appearing some problems, which were solved with some efforts.
For start in threaded mode I used a script, I only changedfrom fcgi import WSGIServer to from flup.server.fcgi import WSGIServer WSGIServer(application=wsgiApp).run() to WSGIServer(application=wsgiApp, bindAddress=
('127.0.0.1', 8900)).run()
Configuration files of web-server: Project codes for every framework: Start script of PHP-FCGI: Web-server results for comparison: Results for frameworks each taken separately:
- 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 (error is taken out)
-
Test Apache Benchmark
- Table of inquiry working speed

* 1) in second time framework is down
* 2) a multiplication factor according to Kovyrin = 1.29. For conversion of performance from mongrel into fastcgi.
- Diagram of results. Test „ab c 5 n 1000“.

- Diagram of results. Test „ab c 100 n 10000“.

- Memory expense before and after tests
* 3) The python is made so, that it restarts the processes at strong load in prefork-mode. Therefore it is impossible to determine real load of processor and maximal use of memory.
- VSZ "virtual set size"

- RSS "resident set size"

- CPU loads

- Table of inquiry working speed
- Test http_load
- Siege test
Conclusions:
Results are visible according to tables and diagrams.
Some short additions:
Django has the least use of the processor.
Catalyst has surprised. By excessive test it overloads the processor. But losses of inquiries were not observed.
RoR 1.2.1 also loads the processor under big load.
It was interesting by TurboGears, which has shown low time use CPU in test "ab", but in the siege-test had the worst result.
Catalyst has appeared the greatest memory use. By RoR this more likely happens because of start through mongrel.
PHP-frameworks borrow many resources CPU even in a quiet condition.
Average connect time is approximate equal for all frameworks. The first response time differs strongly from each other. Django is exception, having the least “average time”, and the highest “maximal time”. Python-frameworks have proved good oneself, and RoR has disappointed.
During the siege-test by CodeIgniter, Symfony, RoR 1.2.1 and 1.1.6 losses were observed at a large number of "concurrent users".
RoR is fast by the small load, but it sharply loses productivity at a plenty of users.
Psyco module accelerates Django on 15-30 %, but it will be worth the grown memory use VSZ on 80 % in a prefork-mode and on 400 % (!!!) in threaded-mode. Use of RSS memory increases in 2-2.5 times.
The Prefork-mode takes away more memory, but for it the system comes out, which stably works on extreme loads, and the smaller use of the processor resources.
In a threaded-mode Django hanged under the big load and did not answer on inquiries.
The same happened with TurboGears too. This is due to the fact that python works badly in a treaded-mode.
Comments from Ivan Sagalaev:
Yes, it is 32 bit system."- FastCGI - server is started in a threaded-mode. It is known, that the Python works in treads essentially slow through GIL (Global Interpreter Lock), because of which all treads wait each other: the interpreter can be used of only one of these. Therefore in Unix at the opportunity servers with python-code should be started in a prefork-mode – it will be faster. By the way, in Windows this situation is reverse, because there creation of process is essentially slower than in Unix. And as far as I know, Python however hangs there less.
- About Psyco. Django-developers have tested it, and have found something interesting. On 32-bit systems it really gives an increase in productivity. And on 64 bit - on the contrary productivity sinks. It happens, because the processor switches under Psyco to a 32-bit mode and does not use all advantages of one’s own architecture. If it is so, than this fact, that Django worked more quickly under Psyco, very likely means, that Linux and Python don’t use 64 bits system (in spite of work on Opteron). That’s right?”
Distribution of places according to this test:
- Django has won over the nearest competitors with the approximate triple superiority.
- Second and third places have divided TurboGears and RoR 1.1.6, because they are equally fast, but behave differently at different loads, overtaking each other.
- .
- Catalyst. To be honest, I expected a good deal more from Perl-framework.
- CodeIgniter. Just as expected PHP-frameworks have appeared the slowest. But CodeIgniter is to recommend those who wish to program only on PHP, and also to have handy system.
- Results of RoR 1.2.1 shocked “a little”: falling of productivity in 2-4 times in comparison with 1.1.6 version. The response-time in http_load is also more in 2 times and excessively high CPU-load under high stream - all this attests to possible error in the new version.
- Symfony has got last place. It is very complicated and slow framework. A difference with Django is up to 35 (!!!) times.
P.S. Because of the addition to Django of the module Psyco in test I have conducted at many requests a short test for PHP with eAccelerator-0.9.5.
I have used 2 times in succession the following commands:
ab -c 5 -n 1000 http://ci.test.com/ ab -c 100 -n 10000 http://ci.test.com/As a result CodeIgniter works 6,5 times faster, gives out to 600 resquests / sek.
The difference with Django became to 2 times.
Here are the results
English









(153 votes, average: 4.5 out of 5)

Januar 29th, 2007 at 11:27 vorm.
1. А почему не учли тот факт, что php по большей части ставится и используется как модуль апача и в таком случае он работает быстрее?
2. Жаль, что в тестировании не участвовал CakePHP (cakephp.org).
Januar 29th, 2007 at 11:49 vorm.
Для Pento:
PHP в FastCGI-режиме + nginx работает производительнее, чем Apache + mod_php.
Вопрос к автору: PHP был с ускорителем/кешем или без?
Januar 29th, 2007 at 11:57 vorm.
Отличный тест, спасибо за проделанную работу.
Хотел бы заметить, что в больших боевых проектах php редко используется без всяческих memcached'ов, zend optimizer'ов и прочих. Этот фактор сильно влияет на производительность. Странно, что про это в статье нет ни слова, а вот про питоновский psyco не забыли, ага.
Januar 29th, 2007 at 1:19 nachm.
У Вас в perl, простите, хрень какая-то в отчёте.
Запрашиваете один документ (/), а получаете - совсем, совсем другой (/hello/). Значит, для одного фреймворка тестировали ещё и редиректы в нагрузку.
Разброс min и max time для запросов косвенно указывает на то, что какие-то модули могли докомпиляться после рестарта фреймворка. Почему не делали "пустой" прогон теста, чтобы всё что нужно было уже откомпилированным в памяти перед основным запуском?.
Что тестировали, собственно, тоже не понятно: делаются ли проверки ACL при доступе к ресурсам? Как ведут себя встроенные template движки (вы же их используете) на больших страницах с малым количеством динамики, на больших страницах с больших количеством динамики?
Januar 29th, 2007 at 1:47 nachm.
Жаль, что Zope никак не учавстовал.
Januar 29th, 2007 at 2:02 nachm.
2 Pento: Про апач BOLK уже ответил, а на CakePHP можно взглянуть...
2 BOLK, zhulanov: PHP был без ускорителя и без кеша. я старался снизить посторонние влияния, то что psyco протестировал, так это для сравнения с самом django. Конечно и зенд и кеш сильно ускорят работу. Но это уже связки.
2 thenexus6: Спасибо, исправил. реально тестировал с прямым линком http://ct.test.com/hello/
Про подгрузку подулей в перле не подумал. Мой косяк. В других тестах прогонял по 2-3 раза, а http_load сделал один раз.
>>Как ведут себя встроенные template движки (вы же их
>>используете) на больших страницах с малым количеством
>>динамики, на больших страницах с больших количеством
>>динамики?
цель тестирования была одна маленькая страничка. и маленькая динамика.
Конечно можно тестировать все фреймворки со всеми ускорителями/без них, с проверкой ACL и без нее, с кучей динамики и не очень. с кучей темплейтов и с одним. еще кучу режимов для всех тестовых программ использовать.
Но этот тест дает только общее представление о производительности фреймворков. А вот конкретный проект каждый должен сам тестировать, и находить подходящий для него вариант.
Januar 29th, 2007 at 2:18 nachm.
Когда я у себя тестировал Ruby on Rails, то он действительно просаживался, будучи запущенным через mongrel.
Однако запущенный через lighttpd + fastcgi (модуль ruby-fcgi native, не pure ruby режиме) (команда запуска: script/server lighttpd) он не только показывал большую производительность (35 страниц/сек вместо максимального 29 через mongrel), но и не проседал - т.е. даже под 200 пользователями показывал те же 35 страниц в секунду.
Januar 29th, 2007 at 2:23 nachm.
Кретив - газетный, автор - метролог...
Писькомерка с погрешностями. Ведущие - это по чьему мнению? По мнению автора?
А где Zope питоновский?
Где CakePHP? Почему выбрали среди PHP фреймворков одну из самых медленных?
И если уже ROR юзали на Mongrel в родных условия, могли бы PHP в mod_php проверить. :(
Januar 29th, 2007 at 2:24 nachm.
И php обязательно нужно с ускорителем (тот же eAccelerator).
Ибо:
1. в python, ruby, perl компиляция кода фреймворка происходит лишь один раз, а в php без акселератора - каждый.
2. ни один нагруженный сайт на php не идет без акселератора
3. (как следствие) ни один хостер не запускает php без акселератора.
Т.е. сравнивать с php без акселератора не честно
Januar 29th, 2007 at 6:06 nachm.
Бред. Еще один синтетический тест не имеющий отношения к реальности.
Januar 29th, 2007 at 6:15 nachm.
Еще бы с БД тесты увязаны были
Например отобразить 50 строк из одной и той же таблицы
А то есть подозрение что работа с БД в джанге любимой тормозид )
Januar 29th, 2007 at 6:42 nachm.
Sorry, was ist mit Cake? Soviel ich weiß, codeigniter ist kein bestes unter PHP frameworks...oder?
Januar 29th, 2007 at 6:53 nachm.
To thenexus6, Alexandr Kot, savagex Ну вы блин даете, нытики несчастные! Чел потратил время – работа не малая, тест познавательный. Обнародовал, так сказать для нужд всеобщих, умные возьмут что-то для себя.
Аффтар респект, не слушай никого, всегда найдутся, которые обсирают всех и все без разбора, и без реального понятия и объяснить то не могут: «Ведущие - это по чьему мнению?» ну напиши свое мнение. А его нет, они просто ходят по блогам и в коменты срут, где придется.
«Бред. Еще один синтетический тест не имеющий отношения к реальности.»
ты сам бред несешь, он о кирпиче, а ты о яйцах, ясно же написано – это только ориентиры, направление,а для каждого проекта все очень индивидуально.
Найми пару работничков, поработайте пару месяцев бесплатно и сделай себе «несинтетический тест, имеющий отношение к реальности»
Januar 29th, 2007 at 7:27 nachm.
Почему не Python-2.5? И где CakePHP?
Januar 29th, 2007 at 9:45 nachm.
> Psyco модуль ускоряет django на 15-30%, но за это приходится расплачиваться возросшим потреблением памяти VSZ на 80% в prefork-режиме и на 400% (!!!) в threaded-режиме.
Дело всё в том, что использовался psyco.full(), а если делать хорошо, то по идее надо профайлером посмотреть, где именно тормозит, и отдавать на ускорение только части. Ну да это очень долго, и заниматься таким стоит только от безысходности :)
Januar 29th, 2007 at 10:01 nachm.
Rails' development mode = slow. Doh. It reloads the entire application on every request.
Try again: `mongrel_rails start -e production`.
Januar 29th, 2007 at 10:18 nachm.
Great work! Thanks for your efforts.
And the django-searchengine was very opportunely ;)
Januar 29th, 2007 at 11:03 nachm.
Работаю с RoR давно, и связка mongrel + Apache mod_proxy_ballancer работает очень шустро.
Januar 29th, 2007 at 11:34 nachm.
Ответ от читателя:
PHP был с ускорителем/кешем или без? - это до лампочки в контексте разов.
Januar 29th, 2007 at 11:37 nachm.
Жаль, что не протестировали какую-нибудь отечественную разработку, например, Cairo (http://www.cairo.com.ua)
Januar 30th, 2007 at 12:31 vorm.
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
Januar 30th, 2007 at 12:33 vorm.
2 Boo
Попробую этот фреймворк в ближайшее свободное время. Хотел сегодня еще сделать, установил, запустил, но не получилось быстро разобраться с проектом.
Januar 30th, 2007 at 12:35 vorm.
2 Jules:
Thanks, it’s a misprint, I have really used production, already corrected :-)
Januar 30th, 2007 at 1:55 vorm.
2 framexpert:
Каиро - это CMS, а я тестировал только CMF, причем только современные MVC
Januar 30th, 2007 at 9:26 vorm.
Работа большая и полезная. Хотелось бы, чтобы автор повторил тесты (через некоторое время) с учётом высказанных замечаний и предложений.
Januar 30th, 2007 at 2:41 nachm.
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 ;)
Januar 30th, 2007 at 4:58 nachm.
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.
Januar 30th, 2007 at 7:41 nachm.
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.
Januar 31st, 2007 at 12:59 nachm.
thanks
Januar 31st, 2007 at 6:32 nachm.
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))
Januar 31st, 2007 at 7:56 nachm.
I’ll try to take into account all wishes and to post additional results as fast as possible
Januar 31st, 2007 at 8:40 nachm.
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.
Januar 31st, 2007 at 11:32 nachm.
This is only results for THIS SMALL project "Hello World" ;)
The test is only like a direction.
Februar 1st, 2007 at 10:42 vorm.
> 1. в python, ruby, perl компиляция кода фреймворка происходит лишь один раз, а в php без акселератора - каждый.
такое может быть только в cgi режиме, через fastcgi или mod_php - все скрипты висят в памяти постоянно.
акселлератор тут не причем. ..насчет хостеров - у них его точно не стоит т.к. он не понимает свежих версий php и вообще не любой код может через него работать.
что касается memcached - причем тут php? Его использовать можно из любых языков, но это отдельная история и в тесте неуместная совершенно.
> Бред. Еще один синтетический тест не имеющий отношения к реальности.
+1. тест абсолютно не о чем, разве что - иллюстрация неправильной установки этих самых фрейморков. более того, он вреден т.к. кто-то это может серьезно воспринять.
"Мне важно было определить скорость работы именно движка MVC фреймворка" - забавная тема для теста, но следовало бы написать большими буквами, что к реальным приложениям он отношения не имеет т.к. многие читатели этого не осознают.
Почему nginx? Патриотизм? ligthttpd был бы более уместен..
Почему fastcgi через tcp, а не через сокет?
Psyco работает только на x86..
"питон не очень хорошо работает с тредами." - lol
Februar 1st, 2007 at 11:24 nachm.
>когда не получается меряться удобством и практичностью, меряются скоростью
Кому нужна практичность и удобство при кривом коде и ужасной производительности ? Я до тошноты нагляделся на красивые и удобные PHP проекты, которые жрут по 20 Мб памяти и делают по 100 запросов к MySQL на каждое обращение к странице.
Februar 1st, 2007 at 11:25 nachm.
> остальные фреймворки компилят свой код лишь однажды, php без акселератора - на каждый запрос
как это кривье написали, так и сравнивают. все честно.
Februar 1st, 2007 at 11:25 nachm.
а помоему, руби - более интересный язык, чем питон.Учитывая несильное отставание в производительности я бы выбрал более интересный инструментарий.
Хотя, конечно, этот фактор не определяющий в данном вопросе. (и субъективный)
Februar 1st, 2007 at 11:26 nachm.
what about Zope? а что про zope автор скажет?
>>>
django - как самый удобный, практичный и, как оказалось, самый скоростной
<<<
хотелось бы услышать сравнение и по Zope, особенно в плане практичный и удобный...
Februar 1st, 2007 at 11:27 nachm.
Zope - страшный тормоз. Говорю как человек писавший и под чистый зоп и под plone.
Februar 1st, 2007 at 11:28 nachm.
Респект за подробное тестирование без marketing shit. За PHP обидно, какой то он ну уж очень тормозной получился... сам сейчас на 5ке пишу, заставил задуматься... С другой стороны памяти мало потребляет, в апачь модулем встраивается, этим обусловлен успех и любовь среди хостеров вероятно...
Впрочем питон сейчас тоже mod_python'ом у многих хостеров стоит, со следующего проекта подумаю перейти на него.
Februar 1st, 2007 at 11:29 nachm.
А по-моему всё это тестирование сплошной marketing shit. RoR позиционирует себя прежде всего как платформу для быстрой разработки, но не для быстрой работы. Это всё равно что сравнивать "кто быстрее довезёт килограмм яблок из Москвы в Питер? Камаз или Ferrari" Довозит быстрее Ferrari, но ведь Камаз и не пытался за ней угнаться.
Кстати, тема озаглавлена "Почему RoR-1.2.1 так глючит?", но никакого описания "таких" глюков я тут не вижу.
И ещё, в самом начале статьи указаны три требования к платформе которые мне кажутся уж если не противоречащими, то соперничающими.
Februar 1st, 2007 at 11:29 nachm.
Вопрос нужно поставить так: почему RoR v.1.2.1 работает в два раза медленнее, чем v.1.1.6? Только бросать его нужно в maillist RoRа, а не сюда.
На этот тест человек потратил немало времени. Нужно спасибо сказать. Может, отправить ему письмо, в котором написать, что он делал не так? Или самому провести тест?
Тест проведён действительно неплохо, есть общие замечания, все они высказаны в комментариях по ссылке. Выскажите свои, никто не запрещает.
Он никогда скоростью не отличался. Он берёт другим. Дешевизной рабочей силы.
Februar 1st, 2007 at 11:30 nachm.
Несмотря на то, что это приятно, все же надо помнить, что это только URL маппер и шаблоны. То есть для реальных приложений будет другая статистика. Все равно, конечно, Django быстрее, но не настолько.
Februar 1st, 2007 at 11:31 nachm.
Было бы интересно также замерить насколько Django становится медленней относительно "hello world". Таким образом, HW это будет универсальная единица производительности и можно будет смотреть насколько падает в HW производительность при увеличении сложности задачи в разных фреймворках. Даже графики сравнительного измнения HW в зависимости от типа задачи можно строить.
Потом жаль, что забыли про java. По легенде java быстрее питона в несколько раз и было бы интересно посмотреть на Tomcat+Struts или +Spring MVC.
Februar 1st, 2007 at 11:32 nachm.
сделал небольшой тест - рабочее приложение, добавил контроллер,
отключил AuthenticatedSystem, но все плагины остались.
ab -n 20 http://localhost:3000/test
Requests per second: 22.07 [#/sec] (mean)
после добавления session :off
Requests per second: 60.95 [#/sec] (mean)
Februar 1st, 2007 at 11:33 nachm.
> а ты уверен что цепляются новые
> рельсы а не старый гем? это зависит от
> boot.rb
environment.rb, там ведь версия рельс
прописывается.
Но лучше все таки стереть старые
версии.
Februar 1st, 2007 at 11:34 nachm.
ты прав, проверил и там была прописана старая версия.
только существенно она ничего не изменила. я провел дополнительно
тест, при этом удалив из gems 1.1.6
Скорость возросла в полтора раза, но все же существенно меньше, чем у
1.1.6 , до двух раз.
Полные результаты выложу на выходные
Februar 1st, 2007 at 11:35 nachm.
Обновил свои приложения до версии 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. Помогите .
Februar 1st, 2007 at 11:35 nachm.
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.
Februar 1st, 2007 at 11:36 nachm.
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
Februar 9th, 2007 at 7:11 nachm.
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
Februar 10th, 2007 at 5:54 nachm.
This is a great comparison. Thank you very much !
März 18th, 2007 at 5:46 nachm.
Респект и уважуха за работу.
März 23rd, 2007 at 1:35 vorm.
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.
August 14th, 2007 at 3:15 vorm.
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
September 12th, 2007 at 10:34 vorm.
I am really fine with this benchmark job. Congratulations.
September 21st, 2007 at 8:04 nachm.
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
Oktober 7th, 2007 at 6:59 nachm.
Скоро выйдут рельсы 2.0, очень хотелось бы сравнение их с джангой.
Oktober 9th, 2007 at 10:19 vorm.
Спасибо! Давай еще! Я новичек и для меня это просто склад информации. Теперь реализовывая какой-либо проект буду смотреть со всех сторон...
Продолжай. Народ просит.
Oktober 14th, 2007 at 11:08 nachm.
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...
November 13th, 2007 at 9:31 nachm.
@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.
Dezember 8th, 2007 at 9:36 nachm.
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.
Dezember 15th, 2007 at 3:52 vorm.
I still think CakePHP is easiest to use, but thats just me...... must have taken a while to conduct these studies.
Dezember 17th, 2007 at 5:43 nachm.
@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.
Januar 22nd, 2008 at 2:30 nachm.
Good , very good SITE !!! THANK YOU FOR THIS site!!
Nice job!Can I put you link on my site?
Februar 7th, 2008 at 9:18 vorm.
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!
Mai 27th, 2008 at 7:11 nachm.
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.
Juli 2nd, 2008 at 12:25 vorm.
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.
Juli 11th, 2008 at 8:06 vorm.
Gr8 work. Can u suggest me how to use psycho in web apps with python
Juli 11th, 2008 at 1:21 nachm.
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...
August 7th, 2008 at 7:11 vorm.
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
Dezember 4th, 2008 at 9:15 nachm.
Приветствую.
Уже давно, и несколько раз, просматривал ваше сравнение.
Можно сказать, одно из самых информативных и полезных, спасибо вам.
Не думали ли вы актуализировать тестирование? Как ни как, почти два года пришло. А тема все еще волнует умы людей ;-)
Заранее спасибо.
Februar 23rd, 2009 at 6:43 nachm.
>2. Жаль, что в тестировании не участвовал CakePHP (http://cakephp.org).
кейк вообще тормоз :(
как насчет теста yii ?
Februar 28th, 2009 at 1:33 nachm.
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!
April 29th, 2009 at 8:10 nachm.
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).
Juni 6th, 2009 at 10:22 vorm.
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.
November 23rd, 2009 at 5:19 vorm.
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_...
März 10th, 2010 at 7:19 vorm.
MVC Catalyst + Moose = The best
April 6th, 2010 at 7:09 nachm.
I made a bit of post on PHP MVC Frameworks in general, might be of interest... http://www.sheldmandu.com/php/php-mvc...
Mai 16th, 2010 at 2:30 nachm.
This is 3-year old now, any update on this?
Juni 10th, 2010 at 6:43 nachm.
It's time for Python framework vs Java framework.
Let's get it on!
Oktober 12th, 2010 at 8:28 nachm.
Жалко, что я пост прочитал уже через пару месяцев как персел на django. Нужно было раньше бросить ковыряние в php. А сейчас приходится все проекты переность, т.к. сервак под CakePHP реально проседает, хотя CakePHP считается более шустрым, чем CI.
Oktober 15th, 2010 at 12:26 nachm.
PHP без акселератора? Неравноценные условия с питоном, т.к. в последнем оптимизация встроена в интерпретатор, а в PHP аналогичные действия просто вынесены наружу — на откуп стороннему п/о. Но без акселераторов в продакшене PHP никто не использует, поэтому получился синтетический тест интерпретаторов языка, а не фреймворков.
Februar 19th, 2011 at 3:28 nachm.
Да, хотелось бы полноценные тесты для PHP CodeIgniter+eAccelerator.. А то за родину абидна=)