Hoy en día, cada vez más aplicaciones se ejecutan en la nube, y están empezando a llevar memcached con ellas. Por ejemplo, como anunciamos a principios de esta semana, casi 300 aplicaciones están utilizando memcached de NorthScale como un servicio en Heroku Plataforma en nube PaaS basada en Ruby.
En el pasado, la mayoría de los entornos que usaban memcached lo hacían en una única LAN controlada: normalmente los servidores web frontales en la DMZ, sin ni siquiera el cortafuegos o router normal entre la DMZ y la base de datos. En este entorno, uno puede esperar razonablemente que los fallos del servidor sean mucho más probables que incluso un solo paquete caído, y esperar una retransmisión es probable que lleve más tiempo que un golpe a la base de datos, por lo que tiene sentido establecer tiempos de espera extremadamente agresivos, del orden de 100-250ms o menos, para las operaciones de memcached.
En cambio, los entornos de redes en nube suelen estar mucho menos controlados, ya que se comparten con otros clientes, e incluso la ubicación de un determinado servicio no está necesariamente bajo el control del usuario. En estos entornos, no es raro que haya tres o más saltos entre nodos, incluso en el mismo centro de datos. Y con otros clientes en el mismo conmutador o el mismo nodo físico, es de esperar que se produzca alguna que otra ráfaga de pérdida de paquetes o alta latencia.
En un entorno de este tipo, incluso con tiempos de espera ligeramente agresivos, un solo paquete perdido puede hacer que falle una consulta. El temporizador de retransmisión inicial de TCP es de 3 segundos. La única manera de intentarlo de nuevo más rápido que esto es darse por vencido y reintentarlo de inmediato. A menos que tu base de datos sea más lenta que esto o particularmente cara, puede tener sentido dejar los tiempos de espera de tu cliente ajustados a sus (probablemente relativamente agresivos) valores por defecto. Sin embargo, dado que ahora es más probable que los tiempos de espera sean causados por problemas de red que por fallos del servidor, es importante que si tu cliente marca los servidores como muertos después de repetidos fallos, esto se afloje un poco. 2 (el valor por defecto en Fauna) es probablemente demasiado ajustado; 3-5 es probablemente un mejor número de fallos antes de marcar un servidor como muerto.
Muchas aplicaciones que no nacieron en la nube no manejarán muy bien los tiempos de espera de memcached. Para tales aplicaciones, puedes considerar ajustar los tiempos de espera para ser capaz de manejar al menos un solo paquete perdido. Los ajustes para Fauna (el cliente Ruby que NorthScale recomienda ya que soporta SASL) se pueden pasar como parámetros hash al constructor del cliente. He incluido recomendaciones para manejar un solo paquete caído:
:connect_timeout - 4.0 - conexión inicial, TCP tardará 3 segundos si se pierde un paquete
:rcv_timeout - not set - libmemcached equivalent is MEMCACHED_BEHAVIOR_RCV_TIMEOUT - tiempo para obtener una respuesta del servidor
:poll_timeout - no definido - el equivalente en libmemcached es MEMCACHED_BEHAVIOR_POLL_TIMEOUT - tiempo que esperamos a que vuelva la llamada al sondeo
:timeout - 4.0 - por defecto para :rcv_timeout y :poll_timeout si no están especificados por separado; esto es lo que se usa normalmente
:retry_timeout - 30 - cuánto tiempo dejar un servidor marcado como muerto cuando alcanza :server_failure_limit
:server_failure_limit - 3-5 - cuantas veces puede fallar un servidor antes de ser marcado como muerto
Todos estos valores están en segundos; Fauna hace la conversión al valor correcto para libmemcached internamente.
