Компания, в которой я работаю, решила перенести весь свой стек в Heroku. Основной мотивацией была простота использования: нет sysAdmin, нет плача. Но у меня все еще есть некоторые вопросы по этому поводу ...

Я делаю некоторые нагрузочные и стресс-тесты как на платформе приложений, так и на сервисе Postgres. я используюblitz как дополнение к Heroku. Я атакую ​​сайт с числом пользователей от 1 до 250. Я получил несколько очень интересных результатов, и мне нужна помощь в их оценке.

Тестовый стек:Технические характеристики

В этом нет ничего особенного.

Rails 4.0.4единорогdatabase.yml настроить для подключения к Heroku postgres.Не использует кеш.База данных

ЭтоСтандарт Тенгу (Соглашения об именах Heroku убьют меня однажды :), правильно подключенный к приложению.

Героку конфиги

Я применил все наunicorn.rb как сказано вРазвертывание Rails-приложений с помощью Unicornстатья. У меня есть 2 регулярных веб-динамо.

WEB_CONCURRENCY  : 2
DB_POOL          : 5

Данныеepisodes таблица насчитывает 100.000 ~episode_urls таблица насчитывает 300.000 ~episode_images таблица насчитывает 75.000 ~Код

episodes_controller.rb

  def index
    @episodes = Episode.joins(:program).where(programs: {channel_id: 1}).limit(100).includes(:episode_image, :episode_urls)
  end

episodes/index.html.erb

<% @episodes.each do |t| %>
<% if !t.episode_image.blank? %>
<li><%= image_tag(t.episode_image.image(:thumb)) %></li>
<% end %>
<li><%= t.episode_urls.first.mas_path if !t.episode_urls.first.blank?%></li>
<li><%= t.title %></li>
<% end %>

Сценарий № 1:

Web dynos   : 2
Duration    : 30 seconds
Timeout     : 8000 ms
Start users : 10
End users   : 10

Результат:

HITS 100.00% (484)
ERRORS 0.00% (0)
TIMEOUTS 0.00% (0)

Эта атака сгенерировала 218 успешных обращений за 30,00 секунд, и мы передали 6,04 МБ данных в ваше приложение и из него. Средняя скорость попадания в 7,27 / секунду соответствует 627 840 ударам в день.

Сценарий № 2:

Web dynos   : 2
Duration    : 30 seconds
Timeout     : 8000 ms
Start users : 20
End users   : 20

Результат:

HITS 100.00% (484)
ERRORS 0.00% (0)
TIMEOUTS 0.00% (0)

Эта атака сгенерировала 365 успешных обращений за 30,00 секунд, и мы передали 10,12 МБ данных в ваше приложение и из него. Средняя частота попаданий 12,17 / сек означает примерно 1 051 200 посещений в день. Среднее время отклика составило 622 мс.

Сценарий № 3:

Web dynos   : 2
Duration    : 30 seconds
Timeout     : 8000 ms
Start users : 50
End users   : 50

Результат:

HITS 100.00% (484)
ERRORS 0.00% (0)
TIMEOUTS 0.00% (0)

Этот порыв произвел 371 успешных обращений за 30,00 секунд, и мы передали 10,29 МБ данных в ваше приложение и из него. Средняя частота попаданий в 12,37 / секунду соответствует примерно 1 068 480 попаданий в день. Среднее время отклика составило 2631 мс.

Сценарий № 4:

Web dynos   : 4
Duration    : 30 seconds
Timeout     : 8000 ms
Start users : 50
End users   : 50

Результат:

HITS 100.00% (484)
ERRORS 0.00% (0)
TIMEOUTS 0.00% (0)

Эта атака сгенерировала 484 успешных хита за 30,00 секунд, и мы передали 13,43 МБ данных в ваше приложение и из него. Средняя частота попаданий 16,13 / сек. Составляет около 1 393 920 посещений / сут. Среднее время отклика составило 1856 мс.

Сценарий № 5:

Web dynos   : 4
Duration    : 30 seconds
Timeout     : 8000 ms
Start users : 150
End users   : 150

Результат:

HITS 71.22% (386)
ERRORS 0.00% (0)
TIMEOUTS 28.78% (156)

Эта атака сгенерировала 386 успешных обращений за 30,00 секунд, и мы передали 10,76 МБ данных в ваше приложение и из него. Средняя частота попаданий 12,87 / сек. Означает примерно 1111680 посещений / сут. Среднее время отклика составило 5446 мс.

Сценарий № 6:

Web dynos   : 10
Duration    : 30 seconds
Timeout     : 8000 ms
Start users : 150
End users   : 150

Результат:

HITS 73.79% (428)
ERRORS 0.17% (1)
TIMEOUTS 26.03% (151)

Эта атака сгенерировала 428 успешных обращений за 30,00 секунд, и мы передали 11,92 МБ данных в ваше приложение и из него. Средняя частота попаданий 14,27 / сек. Составляет примерно 1232640 посещений / сут. Среднее время отклика составило 4793 мс. Однако у вас есть большие проблемы: 26,21% пользователей во время этого спешки испытали таймауты или ошибки!

Общее резюме:«Коэффициент совпадений» никогда не превышает 15, хотя 150 пользователей отправляют запрос в приложение.Увеличение количества веб-динамов не помогает в обработке запросов.Вопросы:

Когда я использую кэширование и memcached (дополнение Memcachier от Heroku), даже 2 веб-динамо могут обрабатывать> 180 обращений в секунду. Я просто пытаюсь понять, что могут dynos и сервис postgres без кеша. Таким образом, я пытаюсь понять, как их настроить. Как это сделать?

Стандартное Tengu, как говорят, имеет 200 одновременных соединений. Так почему же он никогда не достигает этого числа?

Если наличие db уровня prdouction и увеличение количества веб-динамометров не поможет масштабировать мое приложение, какой смысл использовать Heroku?

Наверное, самый важный вопрос: что я делаю не так? :)

Спасибо, что даже прочитали этот безумный вопрос!