Dalli memcache y soporte para race_condition_ttl

By
Anything that can go wrong will go wrong.

El viejo Murphy ten铆a raz贸n (no es la primera vez 馃き). Un Lunes nuestra plataforma amaneci贸 abajo debido a un abrazo de la muerte o deadlock entre hilos tratando de escribir en cach茅 al mismo tiempo.

Buscando la soluci贸n me sorprend铆 al descubrir que Dalli 鈥 la implementaci贸n del cliente memcache que usamos 鈥 hab铆a deprecado hac铆a mucho tiempo el uso de race_condition_ttl, que la documentaci贸n de Rails promete evita que hilos compitan por quien refresca el contenido de la cache una vez que este expira. El cambio hab铆a sido avisado en el changelog de la gema que no siempre leemos cuando hacemos cambio de versi贸n 馃槵.

Sin embargo tambi茅n aprend铆 que ActiveSupport::Cache::MemCacheStore 鈥 desde la versi贸n 4.0 de Rails 鈥 es un thin wrapper de Dalli que mantiene el soporte de race_condition_ttl. Entonces para seguir benefici谩ndonos del feature basta con declarar el uso de mem_cache_store en vez de dalli_store en en la configuraci贸n del ambiente config/environments/production.rb:

# BEFORE
config.cache_store = :dalli_store, {
  pool_size: ENV.fetch(鈥淩AILS_MAX_THREADS鈥, 5)
}
# AFTER (with support for race conditions)
config.cache_store = :mem_cache_store, {
  race_condition_ttl: 10.seconds,
  pool_size: ENV.fetch(鈥淩AILS_MAX_THREADS鈥, 5)
}

El snippet de configuraci贸n de paso muestra el soporte de Dalli que permite usar un pool de conexiones para evitar que la instancia singleton del cliente memcache se convierta en cuello de botella en ambientes multi-thread (d铆gase servidores Puma o Unicorn).



Latest on Blog