Un desarrollador del proyecto memcached explica por qué el sistema no publica métricas internas de tiempo de respuesta: esas cifras resultarían engañosas. Memcached procesa cada petición en menos de un milisegundo, usa un hilo de trabajo por núcleo y mide el tiempo cerca del final del procesamiento, por lo que no captura la espera en las colas del sistema operativo. Cuando el servidor se satura, las peticiones se acumulan en los búferes de red antes de ser leídas, y ese intervalo, que es el que más afecta al cliente, queda fuera del cronómetro interno.
El artículo señala que otras operaciones también distorsionan la métrica: los comandos SET, las respuestas de gran tamaño, el almacenamiento en SSD con extstore y la propia lectura del cliente alargan el tiempo total sin que memcached pueda distinguir la causa. Por eso recomienda medir el tiempo de respuesta desde el cliente, lo que refleja el trayecto completo de la petición y permite correlacionarlo con el uso de CPU, la pérdida de paquetes o cargas masivas de datos.
Como complemento, propone ejecutar un programa ligero en el mismo host que envíe peticiones periódicas y comparar su latencia con la del cliente real: si ambas suben a la vez, la carga del servidor es la causa; si divergen, el cuello de botella está en la red. La documentación oficial incluye un script probador de conexiones y un proxy integrado que registra tiempos muestreados, útiles para iniciar la monitorización.