heroku - memcache - rails etag

Desventajas de rack-caché vs barniz en la pila de cedro Heroku? (4)

Las 2 pilas de aplicaciones anteriores de Heroku incluían una capa de Varnish que automáticamente revertía el contenido del proxy-caché en función de los encabezados http.

La nueva pila de cedros de Heroku no tiene esta capa de barniz. Heroku sugiere usar rack-cache y memcache lugar.

¿Tiene esto desventajas en comparación con las pilas anteriores con la capa de barniz? Con rack-cache, ¿no hay menos servidores que sirven la capa de almacenamiento en caché, y de una manera menos optimizada?

No hay duda de que la eliminación de la capa de barniz es una gran rebaja en el rendimiento de la memoria caché, tanto la latencia como el rendimiento, desde la pila de bambú a cedro de Heroku. Por un lado, sus solicitudes de aplicaciones están compitiendo con, y pueden estar detrás de la cola, hits de caché para el tiempo del dyno.

Las desventajas, por nombrar algunas, son: bloque de memoria interpretado (comparado con C compilado) nivel de aplicación (vs. nivel proxy) basado en memcaches (basado en memoria de proceso) basado en E / S (vs. basado en E / S no bloqueante) . Cualquier sugerencia de que las dos estrategias de almacenamiento en caché puedan competir a escala es ridícula. No verá mucha diferencia a pequeña escala. Pero si tiene cientos o incluso miles de aciertos de caché por segundo, el barniz no se degradará sustancialmente, mientras que la pila de cedro requerirá muchos dynos solo para servir los activos estáticos de manera efectiva. (Estoy viendo ~ 5-10ms de tiempo de procesamiento de dyno para cache hits en cedro).

Cedar se construyó tal como fue construido no para mejorar el rendimiento, sino para introducir nuevos niveles de flexibilidad sobre su aplicación. Si bien le permite realizar operaciones de E / S no bloqueantes como sondeos largos y un control detallado de los parámetros del almacenamiento en memoria caché de activos estáticos, está claro que a heroku le gustaría llevar su propio caché / ancho de banda si su objetivo es la escala de Internet.

No sé cómo se compara el rendimiento de la memoria caché de rack con Varnish en términos de solicitudes sin formato. La mejor opción sería crear una referencia de aplicación sencilla y cambiar de pila.

Vale la pena tener en cuenta que debido a que la pila heroku.com era Nginx-> Varnish-> App, siempre y cuando hayas configurado los encabezados HTTP correctos, tu capa de aplicación hará mucho menos trabajo. Como Varnish administrará la mayor parte de la entrega, así como Varnish será bastante rápido, esto liberará su Dyno para solicitudes de manejo de aplicaciones reales.

Con el stack de herokuapp.com llegando a tu aplicación más temprano, depende de ti y tu aplicación manejar el almacenamiento en caché de manera eficiente, esto puede significar que elijas usar rack-cache para almacenar en caché el resultado de la página completa o puedes elegir usar memcached para atender solicitudes de base de datos o ambos.

Al final, depende de lo que haga su aplicación, si está sirviendo el mismo contenido estático a muchos usuarios, entonces se beneficiaría de Varnish, pero si tiene una aplicación donde los usuarios inician sesión e interactúan con el contenido, entonces ganó No veo que pueda beneficiarse de Varnish, por lo que almacenar en caché el contenido parcial o las consultas de base de datos sin procesar podría ser más eficiente. Si instala el complemento New Relic podrá echar un vistazo bajo el capó y ver qué está ralentizando su aplicación.

También hay opciones de terceros para barniz alojado. Escribí una publicación rápida sobre la configuración con Fastly / Varnish.

Fastly es una solución de barniz alojada que se ubicará frente a su aplicación Heroku y servirá respuestas en caché.

Enlace de actualización: https://medium.com/@harlow/scale-rails-with-varnish-http-caching-layer-6c963ad144c6

He visto tiempos de respuesta realmente buenos. Si puedes obtener un buen porcentaje de aciertos de caché con barniz, deberías poder reducir un buen porcentaje de tu dyno.

Una respuesta más moderna, con 20/20 de retrospectiva:

Para obtener el rendimiento de almacenamiento en caché que se aproxima al de bambú en cedro-14, este es el patrón habitual:

Configure Rails para generar los encabezados de caché apropiados (es decir, Etags, Cache-Control, Last-Modified, etc.)
Adhiere fastly (barniz como un servicio) o cloudflare frente a tu aplicación. Si los encabezados de las aplicaciones se configuraron correctamente, las páginas similares a perfiles que deben estar frescas no se almacenarán en caché, a diferencia de los activos estáticos.

Recomendaría redis-rails como un backend de caché de rack, si está almacenando en caché varias capas (FE (CF / FY), página, acción, fragmento, etc.).