Я бы не решился сказать, что проблема в «взломе».Или действительно, что резьбовые решения обязательно превосходят.
Ситуация является результатом дизайнерских решений, используемых в интерпретаторах таких языков, как Ruby и Python.
Я работаю с Ruby, поэтому детали могут отличаться для других языков.
НО ... по сути, Ruby использует глобальную блокировку интерпретатора для предотвращения проблем с потоками: http://en.wikipedia.org/wiki/Global_Interpreter_Lock
Побочным эффектом этого является то, что для достижения параллелизма с такими структурами, как Rails, вместо того, чтобы полагаться на несколько потоков внутри виртуальной машины, мы используем несколько процессов, каждый из которых имеет свой собственный интерпретатор и экземпляр вашей инфраструктуры и кода приложения
Каждый экземпляр приложения обрабатывает один запрос за раз.Чтобы достичь параллелизма, мы должны раскрутить несколько экземпляров.
В старые времена (2-3 года назад) мы запускали несколько монгрел (или аналогичных) экземпляров за прокси-сервером (обычно apache).Пассажир кое-что изменил, потому что он достаточно умен, чтобы управлять самими процессами, а не требует ручной настройки.Вы говорите Пассажиру, сколько процессов он может использовать, и он отключается.
Вся структура на самом деле не так плоха, как вы могли бы поверить ортодоксии.Для начала довольно легко заставить этот тип архитектуры работать в многоядерной среде.Любая современная база данных рассчитана на одновременную загрузку, поэтому наличие нескольких процессов на этом уровне практически не влияет.
Если вы используете язык, такой как JRuby, вы можете развернуть его на сервере многопоточных приложений, таком как Tomcat, и иметь развертывание, которое выглядит гораздо более «похожим на Java».Тем не менее, это не такая большая победа, как вы думаете, потому что теперь ваше приложение должно быть гораздо более ориентированным на потоки, и вы можете увидеть побочные эффекты и странность от проблем с потоками.