Производительность фреймворков — CodeIgniter уходит в отрыв

Хуан Бассо протестировал несколько современных версий популярных PHP-фреймворков. Увы, оба два моих предпочитаемых: CakePHP и ZendFramework слили CodeIgniter’у по полной программе. В лидерах оказался и неизвестный мне Yii.

Автор тестировал производительность 3-х приложений: стандартного ‘Hello, world’, запрос к базе данных на выборку 10 записей и запрос на выборку 1000 записей. Для тестирования использовался, как я понял, массовый бразильский сервер: Debian, PHP 5.2.0, MySQL 5.0, Apache 2.2.3, процессор Xeon 2.66G и 256 мегабайт оперативки. Всяческие хитрости типа Memcache были отключены и не использовались, все приложения запускались, как принято говорить, в production режиме, т.е. с отключенной отладочной информацией и тому подобное.

Тестовые приложения для каждого фреймворка были разработаны на основе документации, а не взяты из готовых примеров. Это, конечно, может наложить некоторый отпечаток, поскольку вряд-ли Хуан одинаково хорошо разбирается во всех пакетах, зато такой подход наглядно демонстрирует то, что можно получить, если завтра принять решение о смене фреймворка. :-)

В тесте принимали участие самые свежие версии:

Для тестирования использовалась стандартная апачевская утилита ab, измерялось общее количество обработанных запросов за 30 секунд работы. Испытание выполнялось для каждого приложения в двух режимах: с 10 одновременными запросами и со 100 одновременными запросами. т.е. «ab -c 30 -t 10″ и «ab -c 30 -t 100″.

Тест первый: Hello, world!. По горизонтали — количество успешно обработанных запросов.

Производительность приложения Hello, world!

Производительность приложения Hello, world!

CI и Yii очень быстро обрабатывают обращения к сайту. Диспетчеризация, роутинг, подгрузка нужных контроллера и вида. Что касается ZF — я не удивлен, с его обширной файловой системой и количеством файлов это немудрено. Там за один include системе приходится просмотреть пару десятков, а то и больше, директорий. Cake — вот кто удивил. Возможно, время тратится на всяческие преобразования Inflector’ом и обработку умолчаний. Отговорки о том, что CkePHP совместим с PHP4 не помогут. CodeIgniter тоже поддерживает PHP4.

Тест второй: 10 запросов к базе данных

10 запросов к базе данных

10 запросов к базе данных

Здесь отрыв немного сократился, но все равно, лидеры вдвое опережают остальных. Обратите внимание, что производительность практически не меняется в зависимости от нагрузки. Что 10 человек одновременно, что 100. CodeIgniter так даже улучшил производительность при большей нагрузке. Здесь, конечно, сказывается кэширование самого MySQL, если 100 человек одновременно будут открывать разные страницы и генерировать разные запросы к БД, то картина вполне может и поменяться.

Тест третий: 1000 запросов к базе данных. Тест достаточно искусственный, выборка 1000 записей для генерации одной страницы чрезвычайно редкое явление. Этим тестом Хуан решил подтвердить тезис о том, что у всех фреймворков очень большие накладные расходы на обслуживание запросов: составление, выборку результатов, превращение результатов в структуры и т.д. Странно, что ему памяти на машине хватило. Cake, например, выбирает все результаты сразу.

1000 запросов к базе данных

1000 запросов к базе данных

CodeIgniter подтвердил свое лидерство. Но вот, что интересно: ZF практически не сдвинулся с места! Все верно, в ZF можно выбирать результаты построчно. CakePHP, по сравнению с ZF, просел прилично, но все-таки у 1.2 RC4 потеря производительности, относительно теста с 10 запросами, меньше, чем у предыдущей версии 1.1.20. Это вселяет некоторую надежду.

Результаты тестов доступны отдельно здесь.

Опубликовано 26.12.2008 в 03:48 · Автор Сергей · Ссылка
Рубрики: CakePHP · Теги: , , , , , , ,
  • evilbloodydemon

    ога, кодеигнитер ничего не умеет, чего бы ему скоростью не выделяться. статика вон вообще в тыщу раз быстрее.

  • evilbloodydemon

    ога, кодеигнитер ничего не умеет, чего бы ему скоростью не выделяться. статика вон вообще в тыщу раз быстрее.

  • sokol

    Производительность фреймворка обратно пропорциональна его функциональным возможностям, что наглядно и показывают вышеприведенные графики, так-что при выборе фреймворка без компромиса не обойтись.

    Фреймворки созданы для большего удобства и скорости разработки, поэтому следует обращать именно на эти факторы при выборе фреймворка, а оптимизация производительности – это уже последний этап разработки.

  • sokol

    Производительность фреймворка обратно пропорциональна его функциональным возможностям, что наглядно и показывают вышеприведенные графики, так-что при выборе фреймворка без компромиса не обойтись.

    Фреймворки созданы для большего удобства и скорости разработки, поэтому следует обращать именно на эти факторы при выборе фреймворка, а оптимизация производительности – это уже последний этап разработки.

  • http://andrey.opeykin.ru/ xoma

    «а оптимизация производительности – это уже последний этап разработки» – могу с этим не согласиться, о нагрузке, (хотя бы приблизительно) необходимо задумываться с самого начала…иначе, как говорят «коней на переправе не меняют»….

  • http://andrey.opeykin.ru xoma

    «а оптимизация производительности – это уже последний этап разработки» – могу с этим не согласиться, о нагрузке, (хотя бы приблизительно) необходимо задумываться с самого начала…иначе, как говорят «коней на переправе не меняют»….

  • http://ouch.kiev.ua/ Влад

    Сначала думаем об архитектуре, потом уже решаем задачи по мощности. CakePHP на среднепаршивом выделенном сервере с включённым Cache и правильнопостроенной архитектурой, выдержит без особых хлопот 170-200к Уников в сутки.

    Далее не стоит забывать про APC, eAccelerator и Ко.

    И потом, если речь идёт о вашем стартапе, то когда у вас количество уников в сутки будет более 200к – я уверен – можно будет нанять людей которые перепишут и ускорят всё что надо.

    Если вы изначально пишете проект, который (например твиттер-2) будет обязан обслуживать 1 млн уников в сутки, то, ребята. Вы не тот язык выбрали :) воспользуйтесь python-ом, он однозначно будет быстрее.

    А есть ещё и Си. Там тоже будет быстрее.

    Лично я для себя решил решать вопросы последовательно – когда хоть один из моих стартапов достигнет посещаемости в 170к в сутки – тогда либо я нанимаю команду, или перехожу на Python/RoR с mongrel или ваще на C++ ;-)

    Ну и раз уж я начал писать комментарий – случайно наткнулся на сайт, занёс в букмарки. :)

  • http://ouch.kiev.ua Влад

    Сначала думаем об архитектуре, потом уже решаем задачи по мощности. CakePHP на среднепаршивом выделенном сервере с включённым Cache и правильнопостроенной архитектурой, выдержит без особых хлопот 170-200к Уников в сутки.

    Далее не стоит забывать про APC, eAccelerator и Ко.

    И потом, если речь идёт о вашем стартапе, то когда у вас количество уников в сутки будет более 200к – я уверен – можно будет нанять людей которые перепишут и ускорят всё что надо.

    Если вы изначально пишете проект, который (например твиттер-2) будет обязан обслуживать 1 млн уников в сутки, то, ребята. Вы не тот язык выбрали :) воспользуйтесь python-ом, он однозначно будет быстрее.

    А есть ещё и Си. Там тоже будет быстрее.

    Лично я для себя решил решать вопросы последовательно – когда хоть один из моих стартапов достигнет посещаемости в 170к в сутки – тогда либо я нанимаю команду, или перехожу на Python/RoR с mongrel или ваще на C++ ;-)

    Ну и раз уж я начал писать комментарий – случайно наткнулся на сайт, занёс в букмарки. :)

  • гость

    хм… Это все равно что спустить с горы бочку с водой и Мерседес… Мерседес докатится за большее время, но от Мерседеса проку больше чем от бочки…

  • гость

    хм… Это все равно что спустить с горы бочку с водой и Мерседес… Мерседес докатится за большее время, но от Мерседеса проку больше чем от бочки…

  • Zh0rzh

    «ab -c 30 -t 10″ и «ab -c 30 -t 100″ – вот здесь опечатка по моему.

    В обоих случаях -с 30 – это параметр concurrency (параллельность), а -е – это есть время.
    Наверное их нужно поменять местами.

  • Zh0rzh

    «ab -c 30 -t 10″ и «ab -c 30 -t 100″ – вот здесь опечатка по моему.

    В обоих случаях -с 30 – это параметр concurrency (параллельность), а -е – это есть время.
    Наверное их нужно поменять местами.

  • http://coder-life.ru/symfony-vs-codeigniter/ Кодер-лайф.ру » Архив блога » Symfony vs CodeIgniter

    [...] О производительности свидетельствуют многочисленне тесты. Производительность это один из больших плюсов [...]

  • KOT

    Нехило

  • http://juravskiy.ru Vitaliy

    Вообще для высокопроизводительных систем php редко используют, почти никогда.

  • scanner85

    Вот что хочу заметить – порою дешевле разрабатывать быстрее и если не хватает производительности – улучшать железо устанавливая память, более мощный процессор и так далее. Реально – это дешевле. А значит – выгоднее разрабатывать быстро и так, как устраивает твоего работодателя и/или заказчика, а при нехватке производительности – улучшать в первую очередь железо, и конечно, не забывать о возможностях самих фреймворком и апача.
    Всем удач и успехов :)