Давным-давно ещё натыкался на штуковину под названием Quercus в J2EE-сервере Resin. Сейчас решил попытаться на своём сервере сэкономить немножко памяти посредством её использования. Сервер – недорогой двухъядерный AMD x64 Athlon 5600+, ОС Debian, 4GB RAM. Дополнительно: ядро 2.6.32-5-amd64, java version "1.6.0_26", PHP 5.3.8-1~dotdeb.2 with Suhosin-Patch, nginx: nginx version: nginx/1.0.9. Congratulations! Quercus™ Pro 4.0.7 is compiling PHP pages. Have fun! MySQL держит 150 одновременных подключений, nginx – имеет 2 воркера по 1000 подключений каждый, а вот пул php-fpm – имеет всего лишь 50 воркеров (50 воркеров по 64 Мб съедают почти всю память системы, а ведь некоторым задачам в wordpress уже надо по 128 Мб, именно из-за этого я и посмотрел в сторону Quercus). jetty был запущен с ограничением в 1 Гбайт под heap.
Мистическим образом для тестов ко мне попала standalone PRO версия Quercus (умеет компилировать PHP в сервлеты, за счёт чего работает быстрее). Версия эта была для 2х 8-ядерных процессоров, так что ресурсы сервера были задействованы по максимуму.
Были взяты два пустых Wordpress’а, во избежание возможного кэширования запросы к ним выглядели как ?a=b. Первый работал на php-fpm из dotdeb, второй работал на ProQuercusServlet. Прогревание — было, несколько раз порефрешил страницу из браузера (в браузере без ?a=b).
Работой по HTTP занимались с одной стороны — nginx, с другой стороны — jetty 7.4.2.
Итак, что мы видим:
Quercus не оправдал ожиданий. На одиночных запросах результаты сравнимые (около 300 мс), но уже при 100 конкурентных запросах минимальное время на запрос было 5 секунд. Для php-fpm оно составило 2,707 секунды. Максимальные — 35 и 26 секунд соответственно. При этом quercus выдал 877 ошибок. Ошибки на самом деле не были ошибками, документы различались в длину на несколько байт. С виду всё было ОК, как оказалось — страницы отличались фоновым рисунком. Насмотревшись на это безобразие, я переключиля на siege, которому безразлична длина тела ответа веб-сервера.
Jetty мистическим образом раскочегарился, очевидно для Quercus нужно чуть больше, чем несколько раз обновить страничку:
Данные тестирования quercus (разогрев)
ransactions: 700 hits Availability: 100.00 % Elapsed time: 53.71 secs Data transferred: 4.63 MB Response time: 7.53 secs Transaction rate: 13.03 trans/sec Throughput: 0.09 MB/sec Concurrency: 98.08 Successful transactions: 700 Failed transactions: 0 Longest transaction: 14.00 Shortest transaction: 0.26
Во всех запусках имел место подобный разброс: как очень быстрые запросы, так и очень медленные.
Далее было запущено тестирование php-fpm и, как показала практика, тот не отставал (потребление памяти 800 Мбайт). Многократные перезапуски теста улучшений не давали. Получили такие данные:
Данные тестирования php-fpm
ransactions: 700 hits Availability: 100.00 % Elapsed time: 51.10 secs Data transferred: 5.07 MB Response time: 7.00 secs Transaction rate: 13.70 trans/sec Throughput: 0.10 MB/sec Concurrency: 95.85 Successful transactions: 700 Failed transactions: 0 Longest transaction: 10.49 Shortest transaction: 2.87
P.S. Если будете проверять сами — при собственных тестах, чтобы тестирование было справедливым, нужно будет в siege запретить использовать gzip :).
И немножко выводов:
Несмотря на то, что результаты очень близки — quercus всё ещё несколько не дотягивает до php-fpm в плане скорости. Хотя может и обогнать его в экономии памяти. Экономия по сравнению с mod_php – будет видна невооружённым глазом. И php-fpm, и quercus — всячески способствуют масштабированию сервера (quercus scales better, т.к. можно использовать готовые прелести из мира J2EE, такие как JNDI пулы для коннекта к БД).
Ещё одним преимуществом quercus может считаться возможность написания собственных php-экстеншенов на Java. Если в компании уже есть куча кода для JVM, это — серьёзный плюс. Если же наоборот, используются сторонние PECL модули — то quercus вообще не вариант (не поддерживает). Да даже с «поддерживаемыми» PECL модулями вроде zip, у него проблемы.
quercus можно порекомендовать к использованию в системах, в которых экономия памяти более важна, чем скорость процессора.