Инициализация запросов на рельсы

Question

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

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

Answer 1

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

• ли вы используете FastCGI, старой школы, CGI, или какой-либо другой механизм обработки запроса (влияет ли вы будете иметь, чтобы перезапустить весь код инициализации приложения в запросе или нет)
• ли вы используете кэш память (или альтернативную стратегию кэширования) или нет (влияет на стоимость запросов к базе данных)
• ли вы используете дополнительные методы балансировки нагрузки или не
• Какой сессии сохраняемость стратегию, которую вы (при необходимости)
• Wheth er вы используете режим разработки или нет, что заставляет файлы кода перезагружаться всякий раз, когда они меняются (как я помню; возможно, это просто по запросу) или нет

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

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

Answer 2

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

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

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

Насколько мне известно, все претензии довольно фиктивные. «Масштаб» - это архитектурная проблема.

Answer 3

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