Los modos de falla en los sistemas distribuidos son tan variados que es posible que no sea posible determinar si un sistema es lento para responder o está realmente inactivo .
La excepción obvia es si el servicio “falla rápidamente”. Es decir, si recibe una respuesta de error inmediata que le indica que el servicio no está disponible. Por ejemplo, si intento ir a http: // localhost / desde Chrome, aparece la siguiente página de error casi de inmediato.
No se puede acceder a este sitio.
- ¿Cuál es la diferencia entre un archivo y un documento en una computadora?
- ¿Por qué existe la relación de aspecto 16: 9?
- Si un informático se despertara en el año 1500, ¿cuánto tiempo les tomaría construir una computadora con estándares modernos?
- Cómo ver si se está bloqueando la computadora
- ¿Cómo pueden los desarrolladores incorporar inteligencia artificial o aprendizaje automático en su software hoy?
localhost se negó a conectarse.
- ¿Quiso decir http://locallhost.com/?
- Busca en Google localhost
ERR_CONNECTION_REFUSED
Recibo una respuesta similar si intento acceder a Wikipedia en un puerto no estándar (por ejemplo, http://wikipedia.com:12345/). Sin embargo, si intento el mismo truco con Quora, la conexión demora un tiempo (http://quora.com:12345/). Aquí está el mensaje del navegador que recibo de Quora.
No se puede acceder a este sitio.
http://quora.com tardó demasiado en responder.
- Busca en Google quora 12345
ERR_CONNECTION_TIMED_OUT
En ambos casos, el servicio está “inactivo” (es decir, inexistente) pero el comportamiento de falla es diferente. La diferencia podría deberse a las reglas del cortafuegos (por ejemplo, los paquetes a puertos no estándar pueden descartarse silenciosamente), las configuraciones del equilibrador de carga / proxy, la configuración del servidor (incorrecta), etc.
Al intentar contactar con un servicio real, el comportamiento puede ser aún más variado debido a interrupciones parciales. Algunas solicitudes pueden fallar o tardar en responder. Las solicitudes que fallan pueden variar según el cliente, la cuenta, las credenciales, la API, la región o incluso pueden ser aleatorias.
Incluso durante las operaciones “normales”, algunas solicitudes pueden tomar una cantidad excesiva de tiempo. Muchos sistemas tienen algunas condiciones poco frecuentes que pueden ocasionar demoras adicionales (por ejemplo, paquetes descartados, recolección de basura, tener que reequilibrar un árbol, etc.). En promedio, pueden no ser consecuentes. Pero en la rara solicitud donde se desencadenan muchos retrasos simultáneamente, el impacto puede ser sustancial.
Por estas razones, los sistemas distribuidos a menudo se caracterizan por percentiles, no valores binarios de “arriba / abajo”. Como ejemplo, un sistema podría activar una alarma si la latencia del percentil 99.9 es superior a 200 ms, o si la tasa de respuesta exitosa es inferior al 99.999%. (Dado que decir “noventa y nueve punto nueve nueve nueve” es extremadamente engorroso, esto se lee como “cinco nueves”).
También hay una forma bastante estándar de lidiar con problemas de alta latencia / interrupción desde la perspectiva del cliente: retroceso exponencial. La idea es que el cliente continuará reintentando la solicitud hasta que obtenga una respuesta, pero agregará un retraso cada vez mayor entre los intentos de reintento. El aumento es importante para evitar que los clientes sobrecarguen el servidor. De lo contrario, un apagón podría convertirse en un apagón como resultado de los reintentos.
Desde una perspectiva práctica, al cliente no le importa si una respuesta lenta se debe a una interrupción del servicio eléctrico, a un apagón o simplemente a la mala suerte. Lo único que importa es que el cliente no recibió la respuesta en 20 ms, por lo que volverá a intentarlo y esperará 40 ms. Entonces 80 ms. Etcétera. En algún momento, el cliente abandonará los reintentos y mostrará un error de “tiempo de espera excedido” al usuario / llamante.
Es posible que el cliente nunca sepa si el servicio estaba inactivo o si simplemente responde lentamente.
