Индеец Розовое Перо — всех шустрее
Jan. 18th, 2010 09:14 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
shoorickТестирование производительности по-разному запущенного каталистового приложения показывает неожиданные результаты: апач с мод_перлом с точки зрения производительности оказались более предпочтительными, чем другие варианты: и встроенный сервер (как в конфигурации по умолчанию, так и с
Из всех испробованных вариантов помимо чистого апача годится ещё nginx+Apache — статичные файлы можно раздавать nginx'ом, а динамику — апачем. Хотя сам апач прекрасно справляется и с раздачей статики, он жрёт гораздо больше памяти, чем nginx. С учётом того, что аппетит апача в отношении памяти можно ограничить директивами
Производительность можно представить графиком:
Некоторые серверы делали не всё: например, nginx выдавал только статику либо работал прокси-сервером — потому и данные не полны.
Static light — маленький статичный файл легче килобайта, Static heavy — тяжёлый файл (100 кБ), запрашиваемый в 5 и в 100 потоков, Dynamic light — страница, не требующая большого объёма вычислений, показываемая незалогиненному посетителю, Dynamic heavy — страница для залогиненного пользователя.
В чём причина именно таких результатов — пока не знаю.
upd/21.01.2010: Теперь знаю — причина была в том, что на разных серверах использовались разные базы данных.
Более точное тестирование показало равную производительность апача и нгинкса.
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: Теперь знаю — причина была в том, что на разных серверах использовались разные базы данных.
Более точное тестирование показало равную производительность апача и нгинкса.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-01-18 04:34 pm (UTC)Японский товарищ пишет
Date: 2010-01-18 08:28 pm (UTC)no subject
Date: 2010-01-19 10:15 am (UTC)Опубликовать?
Date: 2010-01-19 11:59 am (UTC)Re: Опубликовать?
Date: 2010-01-19 12:23 pm (UTC)Re: Опубликовать?
Date: 2010-01-19 05:02 pm (UTC)посмотреть внимательнее, что там внутри).
no subject
Date: 2010-01-19 05:06 pm (UTC)