Eine Anwendung kann im Einzeltest überzeugen und bei gleichzeitigen Anfragen ins Stocken geraten. Ein brauchbarer Lasttest zeigt Ihrer Organisation, welche Nutzung die Lösung verträgt und wie sie sich an ihren Grenzen verhält.
Gleichzeitige Nutzer sind noch kein Lastprofil
Zwanzig angemeldete Personen erzeugen nicht dieselbe Last wie zwanzig gleichzeitig gestartete Dokumentanalysen. Entscheidend sind die Häufigkeit der Aufträge, ihre Grösse und die einzelnen Verarbeitungsschritte. Eine KI-Agentur sollte deshalb zuerst den Arbeitsablauf mit Ihnen beschreiben, bevor sie eine beeindruckende Zahl gleichzeitiger Nutzer nennt.
Für einen internen Assistenten könnten morgens viele kurze Fragen entstehen, während am Nachmittag wenige grosse Dokumente verarbeitet werden. Erstellen Sie zwei Profile dafür. Halten Sie auch fest, ob jede Person nach einer Antwort weiterfragt oder ob ständig neue Aufträge unabhängig voneinander eintreffen.
Die Dokumentation zu Azure Load Testing beschreibt das Simulieren von Nutzerverkehr, um erwartete Last vor einer Bereitstellung zu prüfen. Das Werkzeug ersetzt jedoch nicht Ihre Entscheidung, welcher Verkehr für das Unternehmen realistisch ist.
Vier Phasen machen einen Test aussagekräftiger
Beginnen Sie mit einer niedrigen Last, um Messung und Testdaten zu kontrollieren. Steigern Sie danach schrittweise bis zum erwarteten Alltagsbetrieb. Eine dritte Phase bildet einen plausiblen Spitzenbedarf ab. Die vierte beobachtet, wie das System nach der Spitze wieder aufholt.
Diese Erholungsphase wird leicht übersehen. Eine Anwendung, die neue Anfragen wieder schnell beantwortet, kann noch eine lange Warteschlange alter Aufträge besitzen. Prüfen Sie deshalb die Zahl offener Vorgänge und das Alter des ältesten Auftrags. Ein grüner Serverstatus allein zeigt nicht, ob die Arbeit aufgeholt wurde.
Lassen Sie ausserdem kurze und lange Eingaben gemeinsam laufen. So wird sichtbar, ob wenige aufwendige Dokumente alle anderen Nutzer blockieren. Das Bulkhead-Muster von Microsoft beschreibt die Begrenzung solcher Auswirkungen durch getrennte Ressourcenpools. Ob diese zusätzliche Architektur nötig ist, muss Ihr Test begründen.
Ein fiktiver Testplan für ein Serviceteam
Angenommen, ein Unternehmen plant einen Assistenten für 30 Mitarbeitende. Nicht alle nutzen ihn gleichzeitig. Die folgenden Werte sind eine frei gewählte Planungshilfe, keine Aussage über die Leistung eines bestimmten Produkts.
Grundlast: fünf aktive Personen stellen über 15 Minuten kurze Sachfragen.
Normalbetrieb: zehn Personen bearbeiten denselben Aufgabenmix während weiterer 20 Minuten.
Spitze: 20 Personen starten zusätzlich einige längere Dokumentaufträge.
Erholung: neue Anfragen gehen zurück; offene Aufträge werden weiter beobachtet.
Daten: freigegebene Testunterlagen mit unterschiedlichen Längen und kontrollierten Zugriffsrechten.
Messung: vollständige Antwortzeit, fachlich brauchbare Ergebnisse, Fehler, Wartedauer und Verbrauch.
Vor dem Start werden Kostenobergrenze, maximale Versuchsdauer und Abbruchbefugnis festgelegt. Der Test erfolgt in einer dafür freigegebenen Umgebung. Reale Kunden dürfen keine Testnachrichten erhalten, und angebundene Systeme dürfen keine echten Bestellungen auslösen.
Fehler sichtbar lassen
Verlangen Sie Ergebnisse für jede Laststufe statt nur einen Gesamtmittelwert. Wiederholte Anfragen, Timeouts und abgebrochene Verbindungen gehören in den Bericht. Sonst sieht ein System mit aggressiven Wiederholungen möglicherweise zuverlässig aus, obwohl es unnötig viele zusätzliche Modellaufrufe erzeugt.
Bei generativer KI sollte eine Stichprobe der Ergebnisse fachlich geprüft werden. Schnell gelieferte, aber unvollständige Antworten sind kein Erfolg. Dokumentieren Sie, ob unter Last eine vereinfachte Verarbeitung aktiviert wurde und ob die Nutzer darüber informiert waren.
Ein weiterer Prüfpunkt ist der Cache. Wenn alle Testpersonen dieselben fünf Fragen stellen, können zwischengespeicherte Antworten ein unrealistisch gutes Bild erzeugen. Vereinbaren Sie deshalb einen gemischten Anteil wiederholter und neuer Fragen und weisen Sie beide Gruppen getrennt aus.
Der Abnahmebericht muss eine Entscheidung ermöglichen
Ein guter Bericht enthält Datum, Konfiguration, Testskript, Datenbestand, Lastverlauf und Ergebnisse. Zu jedem verfehlten Ziel stehen die beobachtete Ursache, eine offene Unsicherheit und die nächste Massnahme. «Mehr testen» ist zu ungenau; «Warteschlange bei langen Dokumenten begrenzen und dieselbe Spitze erneut prüfen» ist überprüfbar.
Fordern Sie keine beliebige Höchstlast, die im Geschäft nie vorkommt. Entscheiden Sie gemeinsam, welche Reserve sinnvoll ist und welche Mehrkosten sie verursacht. Auch eine sauber erklärte Begrenzung kann ein akzeptables Ergebnis sein, wenn das Team mit ihr arbeiten kann.
Der Lasttest ist ein konkreter Teil der Übergabe vom Pilot in den Betrieb. Für die Planung eines passenden Testumfangs kann einclick als Umsetzungspartner für KI Ihre Arbeitsabläufe, technischen Grenzen und Abnahmekriterien zusammenbringen.
