As solicitações lentas no API Gateway afetam outras solicitações?

Uma preocupação frequentemente discutida no âmbito dos gateways de API é a capacidade de lidar eficientemente com um número substancial de solicitações simultâneas. Especificamente, surge a questão: as solicitações lentas aumentarão significativamente o tempo de resposta de outras solicitações normais no gateway de API?

A resposta é que o APISIX se destaca nesse aspecto, demonstrando que as solicitações lentas não impactam negativamente outras solicitações normais. No entanto, para produtos de gateway de API baseados em diferentes linguagens e arquiteturas de software, o desempenho pode não ser tão favorável.

Várias linguagens de programação exibem diferentes graus de afinidade com arquiteturas de software concorrentes. Linguagens de programação antigas, como C e Fortran, projetadas principalmente para sistemas de processador único, possuem suporte limitado para concorrência. No entanto, com o advento de ambientes multiprocessadores e multithreading, linguagens mais recentes como Java e Python incorporam capacidades mais robustas de concorrência e processamento paralelo. Linguagens como Go foram até mesmo projetadas com a concorrência em mente, integrando firmemente seus modelos de concorrência com as características da linguagem. O suporte à concorrência em uma linguagem de programação não apenas reflete o ambiente tecnológico durante sua criação, mas também antecipa seus cenários de aplicação pretendidos.

Supondo milhares de solicitações simultâneas, a utilização de uma arquitetura multithreading ou multiprocessamento (como visto em Java ou Python) exige a alocação de milhares de threads ou processos para gerenciar contextos de solicitação. Aqueles familiarizados com programação de computadores entendem que, mesmo que a maioria das threads permaneça inativa, o sistema operacional incorre em consumo de recursos de hardware para manter milhares de threads ou processos. No entanto, ao usar corotinas (como no APISIX e Golang), threads ou processos adicionais não são necessários, apesar de um aumento nas solicitações simultâneas.

Corotinas, threads e processos representam abordagens para multitarefa, mas exibem diferenças-chave:

1. Mecanismo de Escalonamento: O escalonamento de threads/processos é preemptivo e gerenciado pelo sistema operacional (SO), o que significa que o SO decide quando interromper e alternar para outra thread ou processo. Por outro lado, o escalonamento de corotinas é cooperativo, impulsionado explicitamente por programadores ou bibliotecas de linguagem. As corotinas precisam ceder o controle explicitamente para facilitar a alternância para outras corotinas.

2. Sobrecarga: Threads/processos, estando no nível do sistema operacional, exigem mais recursos para criação, alternância e término. Por outro lado, as corotinas operam no espaço do usuário, resultando em uma sobrecarga relativamente menor para criação, alternância e término.

3. Compartilhamento e Sincronização de Dados: O compartilhamento de dados entre threads/processos exige operações complexas de sincronização, como bloqueios mútuos, bloqueios de leitura-gravação, semáforos, etc., para evitar condições de corrida de dados. As corotinas, estando dentro da mesma thread, podem compartilhar diretamente variáveis globais sem a necessidade de sincronização complexa.

No mundo do APISIX, solicitações lentas envolvem apenas a espera por respostas upstream, um processo limitado à escuta de eventos de rede sem incorrer em sobrecarga adicional de recursos do sistema. Em conclusão, o APISIX não compromete o tempo de resposta de outras solicitações normais devido ao tempo de resposta prolongado de certas solicitações.