Настройка производительности Rails для производства?

Question

Я близок к развертыванию приложения, созданного на Rails 3.1.x, и начал выполнять некоторые тесты производительности.Немного поигравшись с ab, я вижу очень обескураживающие результаты, дающие около 15 запросов в секунду на Heroku.

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

Я использую Unicorn, что примерно на 40% быстрее, чем Thin на Celadon Cedar.Кроме того, я использую общую базу данных PGSQL.

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

Или, если у вас есть солидный практический опыт работы с такими проблемами, как этот, любой вклад будет оценен!

Answer 1

Я провел некоторое время, настраивая свое приложение на heroku, и потратил некоторое время, работая над настройкой производительности приложений Rails с различными настройками.

Когда я запускаю ab -n 300 -c 75 ... myapp.com .... #, который является резервной копией моего основного сайта и находится на бесплатном кедровом плане с единорогом

Requests per second:    132.11 [#/sec] (mean)
Time per request:       567.707 [ms] (mean)
Time per request:       7.569 [ms] (mean, across all concurrent requests)

(это против домашней страницы, которая не делает ничего интенсивного, поэтому я предоставляю это только как «как быстро герой может быть на бесплатном плане с очень простой страницей?», Например, не «ваши приложения должны быть такими быстрыми ")

Вот мой контрольный список настройки производительности Rails 101:

1. Сначала измерьте время загрузки браузера / страницы (браузер делает много запросов, ab только говорит вам об одном из них, и обычно ваш запрос главной страницы не является проблемой), получите базовые номера загрузки страницы из таких инструментов, как www.webpagetest.org или www.gtmetrix.ru для общедоступных страниц или инструменты браузера Yslow, скорость страницы Google или dynatrace для личных страниц.Если вы посмотрите на диаграмму загрузки страницы (панель «Net» в chrome / firefox), она обычно показывает, что ваш html загружается быстро (менее секунды), но затем все остальное занимает 1-3 секунды для загрузки.Следуйте рекомендациям Yslow / page speed по улучшению (убедитесь, что вы в полной мере используете материал конвейера ресурсов Rails 3.1)

2. Прочитайте файлы журналов / новую реликвию, чтобы найтисладкое место запроса «самый медленный / наиболее часто используемый» и профиль того, что происходит с этим запросом (это медленный ruby ​​/ много использования памяти или много запросов?). Вам необходим надежный способ обнаружения и мониторинга производительности.проблемы, а не просто пойти на случайные изменения.После того как вы определили некоторые целевые области, создайте тестовые сценарии, чтобы помочь с ними до и после тестирования, и докажите, что ваши изменения помогают, и определите, не закрадывается ли регрессия.

3. Отсутствие индексов в дБСтолбцы - это одна из самых распространенных проблем, которую проще всего решать.Запустите объяснение для целевых запросов или просмотрите журнал медленных запросов, чтобы увидеть, что делает планировщик запросов.При необходимости добавьте индексы для внешних ключей, столбцов поиска или первичных данных (охватывающий индекс).Повторите тестирование с фактическими данными о производстве, чтобы доказать, что это имеет значение.(вы можете запустить объяснение в heroku, а также выполнить запросы на отсутствующие или неиспользуемые индексы)

4. Большинство плохо работающих приложений Rails страдают от N + 1 запросов, потому что порядок их написания очень прост.owner.address.city и не думайте о том, что происходит, когда это в цикле.N + 1 запросы не обязательно являются медленными запросами, поэтому они не отображаются в медленном журнале запросов, просто их много, и эффективнее делать все сразу.Используйте: include или .include () для быстрой загрузки этих данных или посмотрите на выполнение вашего запроса другим способом.

5. Анализ потока вашего приложения и поиск возможностей кэширования.Если пользователь отскакивает назад и вперед между страницей индекса и страницей сведений и обратно, возможно, просмотр подробностей с помощью ajax, не покидая страницу индекса, даст им необходимые данные быстрее.Я написал больше мыслей об этом в своем блоге

Я выступил с докладом об этих методах и других идеях в Чикаго на конференции WindyCityRails этого года.Вы можете посмотреть видео здесь в моем блоге www.RailsPerformance.com Что мне нравится в heroku, так это то, что вы должны быть масштабируемыми с самого начала.Когда вы посмотрите на обсуждения в списке рассылки, вы увидите, что большинство людей знают о лучших методах производительности и о том, как максимально эффективно использовать сервер.Мне также нравится, как вы, если хотите остаться дешево, узнаете, как уловки производительности производительности, которые принесут вам максимальный эффект.

Удачи!

Answer 2

Есть несколько довольно низко висящих фруктов, которые почти всегда дают довольно достойный прирост производительности:

1. Сократите количество запросов к БД, используя более эффективные операторы ActiveRecord. Обязательно используйте include и join, где это необходимо, и убедитесь, что вы используете empty? над any?, где это возможно, чтобы избежать SELECT s, когда вам просто нужно COUNT.
2. Особенно на более тяжелых страницах, при просмотре в кеш, хотя бы на несколько минут. Вы часто можете разбить большие или динамические части на части, которые также могут быть кэшированы без каких-либо отрицательных эффектов.
3. Перемещение любой активности по сети в фоновые задания. Это включает в себя отправку электронных писем, получение страниц с другого сайта и выполнение вызовов API (даже [особенно?] В Heroku). В Ruby есть несколько действительно хороших библиотек фоновой обработки заданий, DelayedJob очень популярен, потому что он работает с любой базой данных ActiveRecord, но мой любимый - Resque.

Вы должны быть осторожны, чтобы не тратить слишком много времени на оптимизацию процедур Ruby. Если вы не делаете что-то с огромным объемом данных или обработкой (например, изменением размера изображения), вы, вероятно, не увидите очень значительных выгод от оптимизации циклов или минимизации использования памяти. И если вы обнаружите, что некоторые страницы являются проблематичными, покопайтесь в своих журналах и посмотрите, что происходит во время этих запросов.

А если вы еще этого не сделали, приложения для автоматического масштабирования, такие как HireFireApp, отлично подходят для того, чтобы позволить вам обрабатывать множество запросов путем горизонтального масштабирования без затрат на запуск посторонних динамо в медленные периоды.

PS: есть новое дополнение Heroku под названием Blitz , которое позволяет тестировать одновременную нагрузку до 5000 пользователей.

Answer 3

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

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

Answer 4

Поскольку пока ничего не найдено, я предоставлю ответ для части PostgreSQL . Я не могу помочь с Руби.

Вы можете найти отличные отправные точки для оптимизации производительности в вики PostgreSQL.

• Настройка настроек сервера (не уверен, сколько это возможно с Heroku)
• Обратите особое внимание на медленные запросы
• Проверьте ваше оборудование (неприменимо к Heroku)