Сначала запросите к приложению для направляющих, является очень медленным
Как сказал Александр Марграф, вам нужен PyOpenSSL для импорта SignedJwtAssertionCredentials
просто: pip install pyopenssl
ПОМНИТЕ: В Windows произойдет сбой, если у вас не установлены библиотеки OpenSSL Win32 http://slproweb.com/products/Win32OpenSSL.html (вам нужен полный пакет, а не облегченная версия). Также имейте в виду, что вам нужно добавить его к вашему пути var перед установкой pyopenssl
4 ответа
Если вы опубликуете содержимое журнала по мере обработки первого запроса, возможно, мы сможем выяснить, что делает его таким медленным. Например, это мой журнал, когда первый пользователь обращается к сайту
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. Таким образом, ваши пользователи никогда не увидят проблемы.
Крис
Это может быть потому, что вы:
требуете и загружаете несколько плагины и драгоценные камни
, устанавливающие соединение с внешним сервис (затем кеширование)
кэширование ваших собственных страниц и только происходит после первого запроса, если только вы «прогреваете» кэш.
Любой из них неизбежно увеличит время ответа на первый запрос.
Это может быть та же причина, по которой нашим приложениям потребовалось много времени, когда мы впервые запускаем их в Websphere.
WAS должен проделать большую первоначальную работу, чтобы настроить контейнеры при установке новой версии приложения (или перезапуске WAS).
Обходной путь, который мы использовали, заключался в изменении сценариев установки и сценариев запуска WAS таким образом, чтобы они автоматически переходили к приложению (главной странице и выбранным другим страницам) как как только он запустился. Таким образом, первый реальный доступ к нему был на полной скорости.
Я понятия не имею, как это сделать с Ruby и даже возможно ли это. Вам придется это выяснить.
Думаю, вы используете Ferret для полнотекстового поиска? Может быть, соединение хорька требует времени для инициализации? Когда я проверяю ваш журнал, мне кажется, что и db, и view занимают нормальное время, но в целом все равно 10 секунд. Так что я должен быть кем-то другим, поэтому я предполагаю, что Феррет может быть проблемой.