Да, еще. У нас практически все компоненты запускаются во множественном числе. Чатов, к примеру, может быть много — и пока они разделяют один redis, работающий на этом же сервере — они дешевые.
Процессов, обслуживающих общие данные о пользователе (с ними общаются другие компоненты, тот же чат) — больше. На один сервер они не помещаются. Поэтому такие процессы шардятся. В одном узле шарда (физическом сервере) крутятся сразу несколько процессов, работающих на единый редис — опять все быстро.
Не хватает — меняем правила распределения для шарда (тут нужна процедура миграции шарда со старой на новую схему, ее запускать приходится крайне редко) — и опять можем наращивать производительность «на лету».
Отваливаются отдельные процессы в шарде — но их соседи на том же узле временно берут на себя дополнительную нагрузку, пока монитор перезапускает уронившийся процесс.
При такой схеме асинхронность совсем не нужна. Её можно использовать, да только выгоды никакой нет.

poltergeist
В Mongrel2 это вообще должно быть просто, т.к. никто обработчиками не управляет, они сами встают в строй и если помрут - этого никто не заметит.

Ну, вообще то не совсем так.
У них есть собственный Procer, который может работать в 2 режимах:
постоянное слежение за запущенными им же воркерами и перезапуск зависших;
запуск вручную с автоматическим подхватыванием работающих воркеров, слежение за ними и т.д. по первому варианту.

А если предпочитаете работать с другими средствами (daemontools, например) - всегда пожалуйста.

Андрей Светлов
Если монолит в 500 обработчиков на гринлетах занимает 100% CPU и при этом кушает память как не в себя — трудно найти конкретного виновника.

Андрей, здесь и дальше по тексту, это вы о Монгреле2?

Андрей Светлов
Обработчик имеет верхнеуровневый класс компонента. В классе создаются объекты сокетов, редиса и т.д. Всё, естественно, обёртки над низкоуровневыми I/O.

В Брубеке обработчики (воркеры) независимы и могут быть написаны на любом из поддерживаемых Монгрелом языках.
Исходя из описания Брубек и Монгрел2, я вполне реально представляю себе систему, которая через единые ворота обслуживает все запросы корпорации:
- вэб-почта;
- хранилище и передача файлов;
- офисные приложения а-ля Гугл Докс;
- видео- и аудио-конференции;
- сайт;
- внутренний чат;
- …
Причем все это может быть на разных платформах, разных языках и оперативно расширяться по первому требованию!

Для вэб, возможно, придется использовать nginx как фронт-енд для SSL. “Возможно”, т.к. у меня нет информации о сравнительном тестировании SSL в mongrel2 и nginx. Единственное, от чего могу отталкиваться,- nginx уже имеет самый мощный алгоритм шифрования, реализованный программно (OpenSSL c ключами Ephemeral Diffie-Hellman). Это будет явно дешевле аппаратной реализации SSL, особенно для планируемых расширяться систем.

Андрей Светлов
При такой схеме асинхронность совсем не нужна. Её можно использовать, да только выгоды никакой нет.

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

Как по мне, асинхронность должна заканчиваться на самом Mongrel2. То, что разработчик цепляет на обратную сторону ZeroMQ сокетов, вполне может быть синхронным.
Про SSL ничего не знаю. Нам не нужно пока.