А смысл?

[shoorick]

Попробовал между клиентом и каталистом воткнуть nginxНу воткнул, ну запустил (настроив выдачу статики nginx'ом, а остального, как и раньше - апачем) - а пользы не видно: как апачные процессы жрали процессор - так и жрут, как mod_perl отъедал всё больше и больше памяти - так и отъедает

Comments

[tarkhil]

ненавижу капчу. Увидел - писать расхотелось.

Смысл в том, что 3-5 толстых апачей могут обслужить десятки клиентов. На одном клиенте вообще можно тестовый однопоточный сервер использовать.

Re: ненавижу капчу

[shoorick]

Я её включил когда-то для нефрендов - тогда набегали спамеры толпами.
Чтобы в следующий раз у вас не пропало желание писать комментарий -
сменил только что настройки: теперь капча - только для анонимов.

Re: 3-5 толстых апачей

[shoorick]

Значит, надо попробовать ограничить максимальное число запускаемых апачей.
Потому что 50 апачей по 100 метров каждый
съедают и физическую память, и почти весь своп.
Надеюсь, пяток апачей, даже раздувшихся до 200 метров - меньшее зло.
Завтра попробую.

Re: 3-5 толстых апачей

[tarkhil]

Кончено. Оставить их пять штук.

Ну... nginx - не магия. Он не может убрать проблем типа утечки памяти или больших требований к оперативке. Он может убрать некоторые симптомы - но этого вполне хватает для практики.

Памяти что mod_perl, что FastCGI, что каталистовский нативный сервер должны жрать плюс-минус одинаково.

[quappa]

Вот когда придёт 1000 людей одновременно и начнут они все с модемными скоростями скачивать эту статику, вот тогда всё будет понятно :)

Вот когда придёт

[shoorick]

0. Ну я-то скачивал не с модемными скоростями а с соседней машины.
Естественно, с высокой скоростью.

1. Похоже, надо всё-таки и дальше оптимизировать сам сайт, а не способ его
запуска - он сейчас при нескольких десятках одновременных соединений начинает
память жрать гигабайтами. Хотя надо всё-таки ещё на FastCGI проверить.

Re: Вот когда придёт

[tarkhil]

0. И в один поток, да? В один поток сервера не тестируют

1. именно так...

Re: Вот когда придёт

[shoorick]

Зачем же в один? Пробовал по несколько десятков - ab это позволяет.

[fms_01]

Так nginx между клиентом и каталистом втыкается по другому.
Апач вообще убирается а backend используется
Catalyst::Engine::HTTP::Prefork или Catalyst::Engine::FastCGI.
Вот тогда и получается выигрыш.
При чем скорость отдачи динамики остается прежней ( по крайней мере у нас на проекте ).
Правда здесь есть одна проблемка. Если используются специфические апачевские модули, от от них сложно отказаться. Хотя основное ( ssl, http auth, rewrite ) nginx делает прекрасно.

Re: модули

[shoorick]

Нет, специфического апачного нет ничего.

[ospf_ripe]

Смысл в том, что можно значительно сократить число процессов апача и сэкономить на этом много памяти, но заметно это будет заметно только при большом числе параллельных запросов.

Re: На большом числе запросов

[shoorick]

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

[simply_a_man]

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