Назад | Перейти на главную страницу

масштабируемость с помощью nginx, пассажира, настройки ruby ​​on rails

Возможный дубликат:
Как вы выполняете нагрузочное тестирование и планирование емкости для веб-сайтов

Привет, ребята, у меня возник вопрос относительно масштабируемости моего приложения RoR.

Мы оптимизировали наше приложение в течение последних нескольких дней, и после запуска blitz.io обратите внимание, что время ожидания нашего приложения истекает после, может быть, 1000 обращений за 30 секунд, мы испытали огромные таймауты. По-видимому, в 1-минутном тесте у 74% пользователей истекло время ожидания.

Посмотрите на производительность моего сайта: http://blitz.io/report/1c8eb2f395a5eadeabd62fd831ada9e5

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

Что обычно делают в этой ситуации? В настоящее время у нас есть один веб-сервер и один сервер базы данных. Будет ли балансировка нагрузки лучшим вариантом?

Есть много разных способов улучшить производительность вашего приложения. Вы уже делаете оптимизацию. Особенно, если начать оптимизацию запросов (т.е. фиксацию для n + 1 запросов). Есть еще 3 области, на которые я бы тоже обратил внимание. Масштабирование по вертикали и по горизонтали (http://en.wikipedia.org/wiki/Scalability#Scale_horizontally_vs._vertically) и интерпретатор.

Мне нравится сначала масштабировать по горизонтали, по крайней мере, немного. Наличие двух серверов приложений и балансировщика нагрузки увеличит количество запросов, которые вы можете обработать, и мне изначально нравится этот подход, потому что один сервер приложений является единственной точкой отказа. Хотя в этой ситуации балансировщик нагрузки становится единственной точкой отказа. Вы можете запустить 2 LB для избыточности, но это немного выходит за рамки вашего вопроса.

После этого масштабировал по вертикали. Если вы используете виртуальные машины, такие как экземпляры AWS EC2, это так же просто, как перейти от, скажем, m1.small к c1.medium. Многие другие облачные провайдеры имеют разные способы перехода на более крупные серверы. Если вы работаете на собственном оборудовании, протестируйте свое приложение и посмотрите, где находится узкое место (вам, вероятно, следует сделать это в любом случае, и сделать это сначала). Если узким местом является память, просто обновите память на своем сервере и повторно проверьте ее. Тогда вы можете обнаружить, что следующим узким местом является ЦП, поэтому вам необходимо его обновить.

Другая область, которую вы должны рассмотреть, - это интерпретатор Ruby, который вы используете. Если вы используете MRI (интерпретатор Ruby по умолчанию), вы оставляете много производительности на столе. МРТ отлично подходит для разработки, но на сайте с большим трафиком я бы не стал его использовать, если бы мог. MRI использует глобальную блокировку интерпретатора (GIL), которая в основном делает ваше приложение однопоточным. Я могу ошибаться, но, насколько я понимаю, каждому процессу нужна собственная копия приложения в памяти. Итак, если у вас есть 8 воркеров, обслуживающих запросы, ваше приложение будет занимать в 8 раз больше памяти.

Есть несколько других интерпретаторов Ruby, таких как JRuby и Rubinius. Я мало что знаю о Rubinius, но, насколько я понимаю, он устраняет GIL и является отличной альтернативой для МРТ с точки зрения производительности.

Хотя я большой поклонник JRuby. Если вы еще не догадались, JRuby - это интерпретатор Ruby, написанный на Java и Ruby. Он очень стабилен и использует JVM, поэтому вы получаете собственный параллелизм. А если вы выбрали Java 7, invokedynamic может встроить вызовы методов после прогрева JVM и повысить производительность языков JVM, как это было бы с собственным кодом Java. С JRuby вместо того, чтобы нуждаться в новой копии приложения в памяти для каждого процесса, он использует потоки, которые совместно используют одну копию приложения в памяти.

Если вы все же решите использовать JRuby, загляните в Torquebox, отличный сервер приложений, созданный на основе JBoss. Ведущие разработчики для JRuby были недавно наняты Red Hat, которая уже наняла разработчиков для JBoss и Torquebox, поэтому я полагаю, что между этими тремя группами существует много контактов.

Общие тесты практически бесполезны, но все тесты, которые я видел и слышал в реальных производственных приложениях, сравнивают MRI с JRuby, увеличение производительности абсурдно. Я не знаю, получите ли вы такие же преимущества от Rubinius, но может быть проще перейти на Rubinius, чем на JRuby.