¿Las solicitudes lentas en API Gateway afectarán a otras solicitudes?

Una preocupación frecuentemente discutida en el ámbito de las puertas de enlace de API es la capacidad de manejar eficientemente un número sustancial de solicitudes concurrentes. Específicamente, surge la pregunta: ¿las solicitudes lentas aumentarán significativamente el tiempo de respuesta de otras solicitudes normales en la puerta de enlace de API?

La respuesta es que APISIX sobresale en este aspecto, demostrando que las solicitudes lentas no afectan negativamente a otras solicitudes normales. Sin embargo, para productos de puertas de enlace de API basados en diferentes lenguajes y arquitecturas de software, el rendimiento puede no ser tan favorable.

Varios lenguajes de programación muestran diferentes grados de afinidad hacia las arquitecturas de software concurrente. Los primeros lenguajes de programación como C y Fortran, diseñados principalmente para sistemas de un solo procesador, tienen un soporte limitado para la concurrencia. Sin embargo, con la llegada de entornos multiprocesador y multihilo, lenguajes más nuevos como Java y Python incorporan capacidades más robustas de concurrencia y procesamiento paralelo. Lenguajes como Go incluso fueron diseñados con la concurrencia en mente, integrando estrechamente sus modelos de concurrencia con las características del lenguaje. El soporte para la concurrencia en un lenguaje de programación no solo refleja el entorno tecnológico durante su creación, sino que también anticipa sus escenarios de aplicación previstos.

Suponiendo miles de solicitudes concurrentes, utilizar una arquitectura multihilo o multiproceso (como se ve en Java o Python) requiere la asignación de miles de hilos o procesos para gestionar los contextos de las solicitudes. Aquellos familiarizados con la programación informática entienden que, incluso si la mayoría de los hilos permanecen inactivos, el sistema operativo incurre en un consumo de recursos de hardware al mantener miles de hilos o procesos. Sin embargo, al usar corrutinas (como en APISIX y Golang), no se requieren hilos o procesos adicionales a pesar de un aumento en las solicitudes concurrentes.

Las corrutinas, los hilos y los procesos representan enfoques para la multitarea, pero exhiben diferencias clave:

1. Mecanismo de Planificación: La planificación de hilos/procesos es preventiva y gestionada por el sistema operativo (SO), lo que significa que el SO decide cuándo interrumpir y cambiar a otro hilo o proceso. Por el contrario, la planificación de corrutinas es cooperativa, impulsada explícitamente por los programadores o las bibliotecas del lenguaje. Las corrutinas necesitan ceder el control explícitamente para facilitar el cambio a otras corrutinas.

2. Sobrecarga: Los hilos/procesos, al estar en el nivel del sistema operativo, incurren en mayores requisitos de recursos para su creación, cambio y terminación. Por el contrario, las corrutinas operan en el espacio de usuario, lo que resulta en una sobrecarga relativamente menor para su creación, cambio y terminación.

3. Compartición y Sincronización de Datos: El intercambio de datos entre hilos/procesos requiere operaciones de sincronización complejas, como bloqueos mutuos, bloqueos de lectura-escritura, semáforos, etc., para evitar condiciones de carrera de datos. Las corrutinas, al estar dentro del mismo hilo, pueden compartir directamente variables globales sin necesidad de sincronización intrincada.

En el mundo de APISIX, las solicitudes lentas simplemente implican esperar respuestas ascendentes, un proceso limitado a escuchar eventos de red sin incurrir en sobrecarga adicional de recursos del sistema. En conclusión, APISIX no compromete el tiempo de respuesta de otras solicitudes normales debido al tiempo de respuesta prolongado de ciertas solicitudes.