Как стать автором
Обновить

Комментарии 14

Я прошу прощения, но неужели действительно 1000 запросов в минуту надо масштабировать? Это же всего 16,6 запросов в секунду в среднем. Для руби это столь серьёзная нагрузка?
Тут зависит от конкретной инфраструктуры. Например, в данном случае как раз было подмечено пару тонкостей, на которых погорели старые добрые RapGenius.
Продолжая ваши рассуждения по скользкой дорожке «средних» измерений — получится менее 60мс на каждый запрос (в непрерывном режиме). В целом это уже может себе позволить очень небольшое количество хоть немного серьёзных приложений (на руби или нет — не важно). Но проекция на реальный мир выглядит еще более отрезвляюще — при среднесуточном rpm 1000, в пиковые часы в реальности ваш rpm превратится в 5000-6000.

У меня есть один проект на rails с среднесуточным rpm ~1400, он крутится на 3х апп-серварх (по 4 ядра) + 2 БД. Загружено это всё в среднем на 20%, в пики — до 80%.
php 2500 000 уников в сутки было 2 проекта.
И 7+ млн уников в сутки одна штука.

До 40 виртуальных машин под фронт, базы, полнотекстовый поиск, кеш.

Поэтому тоже не понял акцента в заголовке статьи на rpm. Вот обзор серверов приложений был полезен для расширения кругозора.
Похоже это первая ошибка.
Примечание: Это технически сложный текст, так что если вы заметите ошибку или неточность перевода — напишите нам, и мы все поправим, чтобы сделать материал лучше.
Нет конечно. Пустой сервер на EventMachine года 2 назад тащил почти столько же, сколько и нода (~3k rps на ноуте). Рельсы, отдающие просто шаблон, ~400rps выдают.
Годная статья, хороший перевод, спасибо! Буду давать новичкам. Единственное – текст неудобно местами читать из-за «псев-до пере-носов» посреди строк.
Да, это какой-то глюк, уже поправили
Что-то я не очень понял… Автор всю дорогу работал только с heroku и описывает большую проблему с балансировкой. Для меня все это выглядит как неуправляемость — большой провайдер «совершенно случайно» осуществляет балансировку нагрузки, в то же время выдавая ее за некую «интеллектуальную», причем никто точно не может сказать как она работает, какой размер очереди и время запроса в очереди. По-моему, бежать надо от таких провайдеров. Тем более что не самые и дешевые тарифы у них.

Автор очень рекомендует ставить nginx перед gunicorn и рассказывает о медленных клиентах. Это, конечно, азбука, и это первое о чем следует знать при выборе того же gunicorn… Но, как я понял из статьи, Heroku уже ставит nginx перед Dyno-контейнером. В чем смысл ставить еще один внутри? Или это был совет без привязки к Heroku?

Webrick? На продакшене? Серьезно? Разве есть случаи когда от него там может быть польза? Возможно я чего-то не знаю, но, мне казалось, что это сервер для разработки и отладки. И вряд ли кто-то его по-другому воспринимает.

Мне статья показалась слишком «многобуковой», очень много воды и повторений одних и тех же мыслей.
Товарищи, рубисты! Скажите 16 запросов в секунду действительно считается большой нагрузкой для руби? Разьве одной слабой VDS не достаточно для такой нагрузки?
Запросы очень разные бывают… Если приземлять на более-менее реальные кейсы(и не рассматривать ситуации, когда возможно целиком страницы кешировать), то нагрузки выше 3000 rpm, как правило, создают проблемы для rails-приложения на 1 физическом сервере приличной конфигурации.
1000 запросов в секунду? Открыл первый попавшийся из своих проектов на джанге — там не в пиковый час две тысячи запросов в минуту, при этом сервера вообще не нагружены.

Я как-то даже не очень понимаю что там масштабировать-то под тысячу
Ну автор же сразу написал что больше 1000 запросов — это слишком сложно и он лучше расскажет про то, что меньше 1000.
Запросы разные бывают. Мы пишем приложение — у нас сначала один запрос обрабатывался несколько квадрильнов лет (мы не ждали, а посчитали). Сейчас, после смены логики и нескольких алгоритмов в ней, 10 секунду примерно. 1000 таких ваш сервер выдержит?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий