Первый запрос к Rails-приложению очень медленный

Question

всегда первый запрос (рабочего сеанса) к моему Rails-приложению отстает. Переход в производственный режим не помогает.

Я использую mongrel, а другие запросы обрабатываются с приемлемой скоростью.

Как это сделать быстрее?

С уважением

Answer 1

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

Booting Mongrel (use 'script/server webrick' to force WEBrick)  
Rails 2.1.0 application starting on http://0.0.0.0:3000  
Debugger enabled  
Call with -d to detach  
Ctrl-C to shutdown server 
** Starting Mongrel listening at 0.0.0.0:3000 
** Starting Rails with development environment... 
/usr/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_controller/mime_type.rb:66: warning: already initialized constant CSV 
** Rails loaded. 
** Loading any Rails specific GemPlugins 
** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). 
** Rails signals registered. HUP => reload (without restart). It might not work well. 
** Mongrel 1.1.5 available at 0.0.0.0:3000 
** Use CTRL-C to stop. 


Processing SessionsController#new (for 127.0.0.1 at 2009-05-26 12:26:00) [GET] 
    Session ID: de2acf074759026e1ed6205724f547a9 
    Parameters: {"action"=>"new", "controller"=>"sessions"} 
Rendering sessions/new 
Completed in 0.00587 (170 reqs/sec) | Rendering: 0.00298 (50%) | DB: 0.00092 (15%) | 200 OK [http://localhost/] 

Я думаю, что 170 Reqs/сек отлично подходит для нашего приложения, но другие могут обнаружить, что медленно. Из статистики вы можете видеть, что рельсы обеспечивают половину времени, затраченного на рендеринг, - в этом случае генерируют HTML для экрана входа. Если этот запрос занял много времени, моим первым портом захода были бы виды и помощники, связанные с экраном входа.

Если у вас есть система, которая требует много времени, чтобы инициализировать себя по первому запросу, то почему бы не быть подлым и написать свою собственную программу запуска, которая сначала запускает рельсы, а затем отправляет поддельный запрос через curl. Таким образом, ваши пользователи никогда не видят проблемы.

Chris

Answer 2

Это может быть по той же причине, как наши приложения занимают много времени, в первый раз, когда мы пнуть их в Websphere.

WAS должен выполнить начальную работу по настройке контейнеров при установке новой версии приложения (или перезапуске WAS).

Обходной путь, который мы использовали, заключался в том, чтобы изменить сценарии установки и сценарии запуска WAS, чтобы они автоматически просматривали приложение (на главной странице и на других страницах) сразу же после его запуска. Таким образом, первый реальный доступ к ней был на полной скорости.

Я понятия не имею, как это сделать с Ruby или даже возможно ли это. Тебе придется это выяснить.

Answer 3

Я думаю, вы используете Ferret для полнотекстового поиска? Возможно ли, что соединение хорька потребует времени для инициализации? Когда я проверяю ваш журнал, кажется, что и db, и view занимают нормальное количество времени, но общее время составляет 10 секунд. Поэтому я должен быть чем-то другим, поэтому я предполагаю, что Ферре может быть проблемой.

Answer 4

Это может быть потому, что вы:

• требует и загрузки ряд плагинов и драгоценных камней

• делает подключение к внешней службы (то кэширование)

• кэширование ваших собственных страниц и что только возникает после первого запроса, если только вы «нагреваете» кеш

Любое из них неизбежно увеличит время отклика первого запроса.

Answer 5

Возможно, вам нужно отрегулировать var в apache conf. Установите его на 0, чтобы никогда не останавливать процесс рельсов.