Недостатки кеш-стойки против лака в кедровом стеке Heroku?

Question

Предыдущие 2 стека приложений Heroku имели слой Varnish , который автоматически кэшировал содержимое с обратным прокси-сервером на основе заголовков http.

Новый стек кедровых Heroku не имеет этого лакаслой.Heroku предлагает вместо этого использовать rack-cache и memcache .

Имеет ли это недостатки по сравнению с предыдущими стеками со слоем лака?С кэшированием в стойке, неужели меньше серверов, обслуживающих уровень кэширования, и менее оптимизированным способом?

• http://devcenter.heroku.com/articles/http-routing
• http://devcenter.heroku.com/articles/http-caching
• http://devcenter.heroku.com/articles/cedar

Answer 1

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

Недостатками, чтобы назвать несколько, являются: интерпретируемый уровень приложения ruby ​​(по сравнению с скомпилированным C) (по сравнению с уровнем прокси), основанный на memcached (по сравнению с памятью процесса), основанный на блокировании ввода / вывода (по сравнению с неблокирующим вводом / выводом) На основе). Любое предположение, что две стратегии кэширования могут конкурировать в масштабе, просто смешно. Вы не увидите большой разницы в маленьком масштабе. Но если у вас есть сотни или даже тысячи попаданий в кеш в секунду, лак существенно не ухудшится, в то время как стек кедра потребует много динамо только для того, чтобы обслуживать статические ресурсы быстрым способом. (Я вижу ~ 5-10мс время динамометрии для попаданий в кеш на кедре).

Cedar был построен так, как он был создан не для повышения производительности, а для введения новых уровней гибкости в вашем приложении. Хотя он позволяет вам выполнять неблокирующие операции ввода-вывода, такие как длительный опрос и точный контроль над параметрами кэширования статических ресурсов, ясно, что heroku хочет, чтобы вы использовали собственную кеширование / пропускную способность, если ваша цель - масштабирование в Интернете.

Answer 2

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

Стоит помнить, что поскольку стек heroku.com был Nginx-> Varnish-> App, если вы установилиправильные заголовки HTTP вашего уровня приложения будут выполнять гораздо меньше работы.Поскольку большая часть доставки будет обрабатываться Varnish, а Varnish будет довольно быстрым, это освобождает ваш Dyno для актуальных запросов на обработку приложений.

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

В концеэто зависит от того, что делает ваше приложение, если оно предоставляет один и тот же статический контент большому количеству пользователей, вы получите выгоду от Varnish, но если у вас есть приложение, в котором пользователи входят в систему и взаимодействуют с контентом, вы не увидитеVarnish может выиграть, поэтому кэширование частичного содержимого или необработанных запросов к базе данных может быть более эффективным.Если вы установите New Relic addon , вы сможете заглянуть под капот и посмотреть, что замедляет работу вашего приложения.

Answer 3

Есть также сторонние варианты для размещенного Varnish.Я написал быстрый пост о настройке с помощью Fastly / Varnish.

Fastly - это решение Varnish для хостинга, которое будет находиться перед вашим приложением Heroku и обслуживать кэшированные ответы.

Ссылка для обновления: https://medium.com/@harlow/scale-rails-with-varnish-http-caching-layer-6c963ad144c6

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

Answer 4

Более современный ответ, с ретроспективной оценкой 20/20:

Чтобы добиться эффективности кэширования, приближающейся к производительности бамбука на Cedar-14, это обычный шаблон:

1. Настроить Rails для генерации соответствующих заголовков кэширования (т. Е. Etags, Cache-Control, Last-Modified и т.как услуга) или cloudflare перед вашим приложением.Если заголовки приложений установлены правильно, профильные страницы, которые должны быть свежими, не будут кэшироваться, в отличие от статических ресурсов.

Я бы порекомендовал redis-rails в качестве бэкэнда кэша стойки, есливы делаете кеширование на нескольких уровнях (FE (CF / FY), страница, действие, фрагмент и т. д.).