Beeinflussen langsame Anfragen im API Gateway andere Anfragen?

Ein häufig diskutiertes Thema im Bereich der API-Gateways ist die Fähigkeit, eine große Anzahl gleichzeitiger Anfragen effizient zu verarbeiten. Insbesondere stellt sich die Frage: werden langsame Anfragen die Antwortzeit anderer normaler Anfragen im API-Gateway erheblich erhöhen?

Die Antwort ist, dass APISIX in dieser Hinsicht hervorragend abschneidet und zeigt, dass langsame Anfragen keine negativen Auswirkungen auf andere normale Anfragen haben. Bei API-Gateway-Produkten, die auf verschiedenen Sprachen und Softwarearchitekturen basieren, kann die Leistung jedoch weniger gut sein.

Verschiedene Programmiersprachen weisen unterschiedliche Affinitäten zu nebenläufigen Softwarearchitekturen auf. Frühe Programmiersprachen wie C und Fortran, die hauptsächlich für Einprozessorsysteme entwickelt wurden, bieten nur begrenzte Unterstützung für Nebenläufigkeit. Mit dem Aufkommen von Multiprozessor- und Multithreading-Umgebungen haben neuere Sprachen wie Java und Python jedoch robustere Fähigkeiten für Nebenläufigkeit und Parallelverarbeitung integriert. Sprachen wie Go wurden sogar mit Nebenläufigkeit im Hinterkopf entwickelt und integrieren ihre Nebenläufigkeitsmodelle eng mit den Sprachfunktionen. Die Unterstützung für Nebenläufigkeit in einer Programmiersprache spiegelt nicht nur die technologische Umgebung während ihrer Entstehung wider, sondern gibt auch Aufschluss über die beabsichtigten Anwendungsszenarien.

Angenommen, es gibt Tausende von gleichzeitigen Anfragen, dann erfordert die Verwendung einer Multithreading- oder Multiprozessorarchitektur (wie in Java oder Python) die Zuweisung von Tausenden von Threads oder Prozessen, um die Anfragekontexte zu verwalten. Wer mit Computerprogrammierung vertraut ist, weiß, dass das Betriebssystem selbst dann, wenn die meisten Threads im Leerlauf sind, Hardware-Ressourcen verbraucht, um Tausende von Threads oder Prozessen zu verwalten. Bei der Verwendung von Coroutinen (wie in APISIX und Golang) sind jedoch keine zusätzlichen Threads oder Prozesse erforderlich, selbst bei einem Anstieg der gleichzeitigen Anfragen.

Coroutinen, Threads und Prozesse stellen alle Ansätze zur Multitasking-Verarbeitung dar, weisen jedoch wesentliche Unterschiede auf:

1. Scheduling-Mechanismus: Das Scheduling von Threads/Prozessen ist präemptiv und wird vom Betriebssystem (OS) verwaltet, d.h. das OS entscheidet, wann es unterbrochen und zu einem anderen Thread oder Prozess gewechselt wird. Im Gegensatz dazu ist das Scheduling von Coroutinen kooperativ und wird explizit von Programmierern oder Sprachbibliotheken gesteuert. Coroutinen müssen explizit die Kontrolle abgeben, um den Wechsel zu anderen Coroutinen zu ermöglichen.

2. Overhead: Threads/Prozesse, die auf Betriebssystemebene arbeiten, haben einen höheren Ressourcenbedarf für Erstellung, Wechsel und Beendigung. Coroutinen hingegen arbeiten im Benutzerraum und haben daher einen relativ geringeren Overhead für Erstellung, Wechsel und Beendigung.

3. Datenfreigabe und Synchronisation: Die Freigabe von Daten zwischen Threads/Prozessen erfordert komplexe Synchronisationsoperationen wie Mutex-Locks, Lese-Schreib-Locks, Semaphoren usw., um Datenrennen zu verhindern. Coroutinen, die sich im selben Thread befinden, können globale Variablen direkt teilen, ohne dass eine aufwendige Synchronisation erforderlich ist.

In der Welt von APISIX beinhalten langsame Anfragen lediglich das Warten auf Upstream-Antworten, ein Prozess, der auf das Abhören von Netzwerkereignissen beschränkt ist, ohne zusätzlichen Systemressourcen-Overhead zu verursachen. Zusammenfassend lässt sich sagen, dass APISIX die Antwortzeit anderer normaler Anfragen nicht aufgrund der verlängerten Antwortzeit bestimmter Anfragen beeinträchtigt.