Rails запрос инициализации

Question

Мы все много слышим о проблемах масштабирования в Rails.

Мне просто было любопытно, каковы фактические затраты на обработку HTTP-запроса в среде Rails. То есть, что должно произойти для каждого поступающего запроса? Есть ли класс разбора? Конфигурация? Установление соединения с базой данных?

Answer 1

На самом деле это во многом зависит от того, какой веб-сервер вы используете и какую конфигурацию используете, не говоря уже о самом дизайне приложения. Проблемы конфигурации и дизайна включают в себя:

• Используете ли вы fastcgi, old-school cgi или какой-либо другой механизм обработки запросов (влияет на необходимость повторного запуска всего кода инициализации приложения для каждого запроса или нет)
• Используете ли вы memcache (или альтернативную стратегию кэширования) или нет (влияет на стоимость запросов к базе данных)
• Используете ли вы дополнительные методы балансировки нагрузки или нет
• Какую стратегию сохранения сеанса вы используете (при необходимости)
• Используете ли вы режим "разработки" или нет, что приводит к перезагрузке файлов кода при каждом их изменении (насколько я помню; возможно, это просто по запросу) или нет

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

Кто-то, кто углубился во внутренности, может, вероятно, говорить более мучительно подробно, но большинство приложений используют либо FastCGI на Apache, либо альтернативный веб-сервер, более удобный для рельсов, что означает, что вы устанавливаете приложение только один раз на процесс.

Answer 2

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

Answer 3

До выпуска Phusion Passenger (он же mod_rails) «стандартом» для развертывания был не FastCGI, а использование кластера серверов Mongrel, работающих под управлением Apache и mod_proxy (или Nginx и т. Д.).

Основная проблема, стоящая за «Rails не масштабируется», заключается в том, что существуют некоторые довольно сложные проблемы с многопоточностью, которые привели к тому, что в текущей версии Ruby и доступных механизмах обслуживания Rails не является поточно-ориентированным. Это означало, что для запуска приложения Rails требовалось несколько контейнеров для поддержки высокого уровня одновременных запросов. Пассажир делает некоторые из этих споров, поскольку он обрабатывает все это внутренне, и также может быть запущен на пользовательской сборке Ruby (Ruby Enterprise Edition), которая меняет способ обработки памяти.

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

Насколько я понимаю, все утверждение довольно поддельное. «Масштаб» является архитектурным концерном.