Как мне выяснить, почему мое приложение rails 3, использующее mod_rails, работает так медленно?
Я разработал небольшое приложение на Rails, используя Rails 3.0.0 и Ruby 1.9.2. Во время тестирования на моем персональном компьютере все в порядке. Я ставлю его на свой VPS для производства, используя Apache и mod_rails, и иногда производительность ужасна.
Вот пример из production.log:
Запустил GET "/tracker" для XX.XX.XX.XX в 2010-11-21 21:49:56 -0500
Обработка FleetsController#index как HTML
Визуализированные макеты /_stylesheets.html.haml (0,8 мс)
Визуализированные макеты /_header.html.haml (1,0 мс)
Визуализированные макеты /_footer.html.haml (0.0ms)
Отображаемые страницы /about.html.haml в макетах / приложениях (4,5 мс)
Завершено 200 OK за 15 мс (Просмотров: 14,3 мс | ActiveRecord: 0,0 мс)Запустил GET "/tracker/" для XX.XX.XX.XX в 2010-11-21 21:50:02 -0500
Обработка FleetsController#index как HTML
Визуализированные макеты /_stylesheets.html.haml (0,7 мс)
Визуализированные макеты /_header.html.haml (1.1ms)
Визуализированные макеты /_footer.html.haml (0.0ms)
Отображается fleets/index.html.haml в макетах / приложении (7,8 мс)
Завершено 200 OK в 1901 мс (Просмотров: 7,8 мс | ActiveRecord: 1,5 мс)Запустил GET "/tracker/fleets/XXXXXXXXX" для XX.XX.XX.XX в 2010-11-21 21:50:06 -0500
Обработка FleetsController # показать как HTML
Параметры: {"id"=>"XXXXXXXXX"}
Рендеринг флотов /_details_inner.html.haml (1,2 мс)
Рендеринг флотов /_details.html.haml (2,1 мс)
Рендеринг флотов /_summary.html.haml (3,5 мс)
Рендеринг флотов /_scouts_inner.html.haml (1,3 мс)
Рендеринг флотов /_scouts.html.haml (3,5 мс)
Предоставленные отчеты /_report.html.haml (0,5 мс)
Рендеринг флотов /_reports.html.haml (3,0 мс)
Рендеринг флотов /_recon_form.html.haml (39,9 мс)
Рендеринг флотов /_recon.html.haml (40,8 мс)
Rendered users / _user.html.haml (1.2ms)
Рендеринг флотов /_pilots.html.haml (1,9 мс)
Визуализированные макеты /_stylesheets.html.haml (0,5 мс)
Визуализированные макеты /_header.html.haml (0,9 мс)
Визуализированные макеты /_footer.html.haml (0.0ms)
Отображение флотов /show.html.haml в макетах / приложениях (60,2 мс)
Завершено 200 OK за 495 мс (Просмотров: 59,1 мс | ActiveRecord: 2,9 мс)
Первый удар не имел доступа к базе данных. Второй действительно имеет доступ к базе данных, но для генерации представлений потребовалось всего 7,8 мс, а для базы данных - всего 1,5 мс, хотя вся страница не была заполнена в течение почти 2 минут! Это довольно распространенный пример, но у меня есть несколько записей журнала с 14+ секундами для ответа страницы. И нет, это не при начальной загрузке рельсов после перезагрузки.
Что может занять это время?
1) Я неправильно истолковал отчеты о времени ActiveRecord, и это на самом деле просто время кода, но время базы данных в реальном времени - это то, куда идет время?
2) Я использую sqlite. Я знаю, что в конце концов мне, вероятно, придется переключиться на MySQL, так как у меня будут проблемы с параллелизмом, поскольку (большинство) при каждом попадании на страницу происходит запись в базу данных. Но сейчас у меня почти нет движения; максимум 15 человек на сайте одновременно. В приведенном выше примере журнала было только 1 попадание за раз, по 4-6 секунд между каждым попаданием. Я думаю, что sqlite может справиться с этим...
3) Я на общем VPS. Это означает, что, возможно, какой-то другой пользователь на VPS одновременно делал что-то, что приводило к замедлению работы сервера. В большинстве случаев мой VPS имеет очень низкую загрузку процессора, но, возможно, мне не повезло, и что-то происходило именно в этот момент. Но я видел, как это происходит достаточно часто, и я не покупаю это как ответ.
4) VPS имеет только 512+512 МБ памяти. Я показываю, что есть 150 МБ свободного места, но возможно ли, что я просто превышаю ограничения памяти, и это перестановка страниц или что-то в этом роде?
5) Я также видел несколько исключений BusyException в журнале. Я увеличил тайм-аут database.yml до 15 секунд (с 5), чтобы посмотреть, поможет ли это. С тех пор я не провела настоящего теста, чтобы увидеть, прошел ли он.
Я знаю, что, вероятно, я не предоставил достаточно информации, чтобы вы могли на самом деле рассказать мне, что происходит, поэтому реальный вопрос в том, как мне вообще начать пытаться отследить это?
2 ответа
Итак, две вещи..
- Используйте New Relic для диагностики медленного кода
- Основываясь на журналировании, я бы поспорил, что вы выполняете некоторые манипуляции с массивами или возвращаете большой массив элементов в FleetsController#index ... похоже, код вашего приложения там что-то делает.
Если это выглядит неправильно, отправьте код в FleetsController # index. Но NewRelic может помочь вам выяснить, где именно вы проводите свои циклы в медленных веб-запросах.
SQLite вообще не выполняет параллелизм. Я думаю, что, возможно, соединения блокируются в базе данных. Реальные запросы в порядке, но я подозреваю, что файл базы данных SQLite заблокирован во время выполнения другого запроса.
Вам действительно нужно перейти на реальную базу данных сервера, такую как MySQL или PostgreSQL.