Плохая производительность с Rack :: Cache

Question

Rack :: Cache настроен как самое верхнее (последнее) промежуточное ПО в моем стеке.Мое приложение размещено на кедре heroku, поэтому Rack :: Cache также отвечает за статические ресурсы.

Оно поддерживается продуктом heroku memcached и настроено так:

config.action_dispatch.rack_cache = {
  :metastore    => Dalli::Client.new,
  :entitystore  => 'file:tmp/cache/rack/body',
  :allow_reload => false
}
config.static_cache_control = "public, max-age=2592000"

работает на тонком.

Я тестирую производительность на файле изображения, используя ab.

ab -n100 -c10 https://example.com/foo.jpg

Глядя в мои журналы, все запросы являются попаданием в кеш( "свежий").Но производительность низкая, всего около 6 запросов / сек.Я знаю, что Rack :: Cache не будет работать так же хорошо, как выделенный http-прокси, но я, конечно, ожидал более высокую пропускную способность, чем эта.

update Не знаю, черт возьмиЯ не думал об этом раньше, но мой эталонный тест действительно максимизирует мое интернет-соединение.Если я выполню тот же тест с robots.txt вместо jpg, я получу 20 запросов в секунду (и все равно буду макс ниже по потоку).

Answer 1

Я заметил, что URL в вашем посте HTTPS. У меня была проблема со стеком кедра с SSL на основе имени хоста, когда некоторые запросы (как для статических ресурсов, так и для других) имели бы высокую задержку, даже если в журналах указывалось, что время очереди было 0 мс, а время обслуживания - 5-10 мс. Вот ответ службы поддержки Heroku (он не упоминает, что лак не кэширует ресурсы, поступающие из приложений кедра, независимо от того, присутствует ли он в стеке при запуске SSL на основе имени хоста):

Мы не совсем уверены, что является причиной этого, но мы подозреваем, что Varnish виноват. Обычно, со стеком Cedar, Varnish нет. Но когда используется надстройка имени хоста SSL, Varnish добавляется обратно в процесс ответа. Нет необходимости использовать Rack :: Cache и Varnish.

Я хотел бы предложить удалить Лак с картинки, чтобы посмотреть, помогает. Способ сделать это - переместить SSL в нашу новую надстройку SSL, SSL Конечная точка. Конечная точка SSL технически все еще находится в бета-версии, но она будет как правило, скоро будет доступен и будет стоить столько же, сколько и SSL Hostname. Это будущее SSL на Heroku, и оно лучше во всех отношениях.

http://devcenter.heroku.com/articles/ssl-endpoint-beta2
пользователь: бета пропуск: ****

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

Мы также рассмотрели возможность того, что ваша текущая конечная точка SSL Amazon ELB, это плохо и нуждается в замене. Но если бы это было В этом случае многие запросы будут медленными или ошибочными, а не случайными один медленный запрос. Замена текущего ELB также будет включать Изменение DNS. Переход на новую надстройку Endpoint SSL создаст Ситуация, как это легче в будущем - если обменять ELB необходимые изменения DNS не понадобятся.

Сейчас я думаю, что переход на конечную точку SSL будет лучшим.

Конечно, время ожидания, которое я видел, иногда доходило до 30-60 ВТОРОГО диапазона, что, очевидно, немного хуже, чем вы видите. Когда я запускаю одни и те же команды Apache Bench для статических ресурсов в некоторых моих приложениях (HTTPS) для кедра, я не чувствую себя намного лучше (10–15 запросов / с). Когда я увеличиваю параллелизм до 50 или 100, число запросов в секунду возрастает до 30. Однако в бамбуковых приложениях HTTPS на основе Varnish я могу увеличить его до 50 запросов в секунду для статического ресурса. Если бы мой компьютер мог обрабатывать более высокий параллелизм, я подозреваю, что он пошел бы еще выше. И у меня интернет с высокой задержкой, так как он в сотовой сети.