Влияют ли медленные запросы в API Gateway на другие запросы?

Часто обсуждаемая проблема в области API-шлюзов — это способность эффективно обрабатывать большое количество одновременных запросов. В частности, возникает вопрос: будут ли медленные запросы значительно увеличивать время отклика других обычных запросов в API-шлюзе?

Ответ заключается в том, что APISIX превосходно справляется с этой задачей, демонстрируя, что медленные запросы не оказывают негативного влияния на другие обычные запросы. Однако для продуктов API-шлюзов, основанных на различных языках и программных архитектурах, производительность может быть не столь благоприятной.

Различные языки программирования демонстрируют разную степень поддержки конкурентных программных архитектур. Ранние языки программирования, такие как C и Fortran, разработанные в основном для однопроцессорных систем, обладают ограниченной поддержкой конкурентности. Однако с появлением многопроцессорных и многопоточных сред новые языки, такие как Java и Python, включают более мощные возможности конкурентности и параллельной обработки. Языки, такие как Go, даже были разработаны с учетом конкурентности, тесно интегрируя свои модели конкурентности с языковыми функциями. Поддержка конкурентности в языке программирования не только отражает технологическую среду во время его создания, но и предсказывает предполагаемые сценарии его применения.

Предположим, что имеются тысячи одновременных запросов. Использование многопоточной или многопроцессорной архитектуры (как в Java или Python) требует выделения тысяч потоков или процессов для управления контекстами запросов. Те, кто знаком с программированием, понимают, что даже если большинство потоков остаются бездействующими, операционная система потребляет аппаратные ресурсы для поддержания тысяч потоков или процессов. Однако при использовании корутин (как в APISIX и Golang) дополнительные потоки или процессы не требуются, несмотря на увеличение количества одновременных запросов.

Корутины, потоки и процессы представляют собой подходы к многозадачности, но имеют ключевые различия:

1. Механизм планирования: Планирование потоков/процессов является вытесняющим и управляется операционной системой (ОС), что означает, что ОС решает, когда прервать и переключиться на другой поток или процесс. Напротив, планирование корутин является кооперативным, управляемым явно программистами или библиотеками языка. Корутины должны явно освобождать управление, чтобы облегчить переключение на другие корутины.

2. Накладные расходы: Потоки/процессы, находящиеся на уровне операционной системы, требуют больше ресурсов для создания, переключения и завершения. Напротив, корутины работают в пользовательском пространстве, что приводит к относительно меньшим накладным расходам для создания, переключения и завершения.

3. Совместное использование данных и синхронизация: Совместное использование данных между потоками/процессами требует сложных операций синхронизации, таких как мьютексы, блокировки чтения-записи, семафоры и т.д., чтобы предотвратить состояние гонки данных. Корутины, находящиеся в одном потоке, могут напрямую разделять глобальные переменные без необходимости сложной синхронизации.

В мире APISIX медленные запросы просто включают ожидание ответов от вышестоящих серверов, процесс, ограниченный прослушиванием сетевых событий, без дополнительных затрат системных ресурсов. В заключение, APISIX не ухудшает время отклика других обычных запросов из-за увеличенного времени отклика некоторых запросов.