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

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

5 голосов
/ 26 мая 2009

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

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

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

Привет

Ответы [ 5 ]

2 голосов
/ 27 мая 2009

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

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

  • подключение к внешнему сервис (затем кеширование)

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

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

1 голос
/ 26 мая 2009

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

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 запросов в секунду - это хорошо для нашего приложения, но другие могут счесть это медленным. Из статистики видно, что rails предоставляет половину времени, затрачиваемого на рендеринг ответа - в этом случае генерируется HTML для экрана входа в систему. Если этот запрос занимал много времени, моим первым портом захода были бы представления и помощники, связанные с экраном входа в систему.

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

Chris

1 голос
/ 26 мая 2009

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

1 голос
/ 26 мая 2009

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

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

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

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

0 голосов
/ 03 октября 2011

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

...