Индеец Розовое Перо - всех шустрее
Тестирование производительности по-разному запущенного каталистового приложения показывает неожиданные результаты: апач с мод_перлом с точки зрения производительности оказались более предпочтительными, чем другие варианты: и встроенный сервер (как в конфигурации по умолчанию, так и с CATALYST_ENGINE='HTTP::Prefork'), и nginx+FastCGI работают заметно медленнее, чем апач.
Из всех испробованных вариантов помимо чистого апача годится ещё nginx+Apache - статичные файлы можно раздавать nginx'ом, а динамику - апачем. Хотя сам апач прекрасно справляется и с раздачей статики, он жрёт гораздо больше памяти, чем nginx. С учётом того, что аппетит апача в отношении памяти можно ограничить директивами MaxClients (апач работал и с пятью дочерними процессами - скорость была не хуже скорости с пятьюдесятью процессами) и MaxRequestsPerChild (время жизни дочернего процесса (в принятых запросах), по умолчанию дочерние процессы живут бесконечно, что в данном случае не годится) - видимо такую систему и придётся сооружать (после того, как разберусь с uri_for).
Производительность можно представить графиком:
Некоторые серверы делали не всё: например, nginx выдавал только статику либо работал прокси-сервером - потому и данные не полны.
Static light - маленький статичный файл легче килобайта, Static heavy - тяжёлый файл (100 кБ), запрашиваемый в 5 и в 100 потоков, Dynamic light - страница, не требующая большого объёма вычислений, показываемая незалогиненному посетителю, Dynamic heavy - страница для залогиненного пользователя.
В чём причина именно таких результатов - пока не знаю.
upd/21.01.2010: Теперь знаю - причина была в том, что на разных серверах использовались разные базы данных.
Более точное тестирование показало равную производительность апача и нгинкса.
Из всех испробованных вариантов помимо чистого апача годится ещё nginx+Apache - статичные файлы можно раздавать nginx'ом, а динамику - апачем. Хотя сам апач прекрасно справляется и с раздачей статики, он жрёт гораздо больше памяти, чем nginx. С учётом того, что аппетит апача в отношении памяти можно ограничить директивами MaxClients (апач работал и с пятью дочерними процессами - скорость была не хуже скорости с пятьюдесятью процессами) и MaxRequestsPerChild (время жизни дочернего процесса (в принятых запросах), по умолчанию дочерние процессы живут бесконечно, что в данном случае не годится) - видимо такую систему и придётся сооружать (после того, как разберусь с uri_for).
Производительность можно представить графиком:
Некоторые серверы делали не всё: например, nginx выдавал только статику либо работал прокси-сервером - потому и данные не полны.
Static light - маленький статичный файл легче килобайта, Static heavy - тяжёлый файл (100 кБ), запрашиваемый в 5 и в 100 потоков, Dynamic light - страница, не требующая большого объёма вычислений, показываемая незалогиненному посетителю, Dynamic heavy - страница для залогиненного пользователя.
В чём причина именно таких результатов - пока не знаю.
upd/21.01.2010: Теперь знаю - причина была в том, что на разных серверах использовались разные базы данных.
Более точное тестирование показало равную производительность апача и нгинкса.