А смысл?

[shoorick]

Попробовал между клиентом и каталистом воткнуть nginx.

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

Скорость выдачи статики у обоих серверов практически совпадает, а на выдаче динамического контента апач даже чуть-чуть шустрее связки nginx+apache (что предсказуемо).

В чём смысл-то? Разве что вынести backend на другую железяку (или завести несколько бэкендов на разных машинах) — может быть, что-то улучшится. Или попробовать FastCGI в надежде на уменьшение потребления памяти? Непонятно.

Толкового мануала к nginx'у нет (во всяком случае, на сайте разработчика). Ни на русском, ни на английском — лишь какие-то обрывки да разрозненные статьи, раскиданные по интернетам. Вот их и придётся изучать...

Comments

[tarkhil.livejournal.com]

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

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

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

[shoorick.livejournal.com]

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

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

[shoorick.livejournal.com]

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

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

[tarkhil.livejournal.com]

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

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

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

Памяти жрать должны одинаково

[shoorick.livejournal.com]

Ну у меня и родной каталистовый сервер, и апач (сразу после перезапуска)
поедают память с одинаковым аппатитом — около 50 МБ на процесс.

Но если родной сервер загрузить — он всё равно будет есть по 50 МБ, а апачные
процессы начинают раздуваться, причём до 200 метров его можно надуть вообще за
несколько минут (если озадачить сайт нагрузочным тестированием).
Но отдавать контент родным сервером вместо апача не годится —
он работает в разы медленнее апача.

Re: Памяти жрать должны одинаково

[tarkhil.livejournal.com]

ну... короче, делай fcgi+nginx))

[quappa.livejournal.com]

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

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

[shoorick.livejournal.com]

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

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

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

[tarkhil.livejournal.com]

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

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

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

[shoorick.livejournal.com]

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

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

[tarkhil.livejournal.com]

несколько десятков ab, одновременно сосущих динамику полным ходом - тоже не совсем то...

Не совсем то

[shoorick.livejournal.com]

А как лучше? Сразу всё высасывать и ходить по ссылкам?

Re: Не совсем то

[tarkhil.livejournal.com]

Я пока что не встречал реальных клиентов, которые бы высасывали-в-максимальном-темпе. Выкачать - статику - "почитать"...

[fms-01.livejournal.com]

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

Re: модули

[shoorick.livejournal.com]

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

[ospf-ripe.livejournal.com]

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

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

[shoorick.livejournal.com]

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

[simply-a-man.livejournal.com]

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