Performance & Last

Richtig: Antwortzeit (wie lange eine Anfrage dauert) und Durchsatz (wie viele Anfragen pro Sekunde verarbeitet werden)

Antwortzeit ist die Sicht des einzelnen Nutzers, Durchsatz die Sicht des Systems. Beide hängen zusammen: Steigt die Last über einen Punkt hinaus, wächst die Antwortzeit stark, während der Durchsatz stagniert.

Richtig: 980 ms

Sortiert: 95, 100, 105, 110, 115, 120, 130, 140, 980, 2500. 90 % von 10 Werten sind 9, also der 9. Wert: 980 ms. Perzentile zeigen, wie es den langsamsten Nutzern geht, und sind deshalb aussagekräftiger als der Durchschnitt. (449,5 ms wäre der Mittelwert.)

Richtig: Durchschnitt 590 ms, Median 100 ms; der Durchschnitt beschreibt keine einzige echte Anfrage

Der Durchschnitt liegt bei 590 ms, aber keine Anfrage dauerte so lange: 9 waren schnell, eine sehr langsam. Der Median (100 ms) zeigt den typischen Fall, ein hohes Perzentil den Ausreißer. Ausreißer einfach zu streichen, versteckt oft das eigentliche Problem.

Richtig: 10

Little's Law: gleichzeitige Anfragen = Durchsatz × Verweildauer = 50 × 0,2 = 10. Damit kann man prüfen, ob Lasttests plausibel sind oder wie groß Thread- und Verbindungspools mindestens sein müssen.

Richtig: Dauertest (Soak-Test): normale Last über viele Stunden

Lecks, volllaufende Logs oder sich füllende Caches brauchen Zeit. Ein Dauertest mit gleichmäßiger Last zeigt sie an einem langsam steigenden Speicherverbrauch. Kurze Tests sind dafür blind.

Richtig: Spitzentest (Spike-Test)

Ein Spitzentest prüft, ob das System plötzliche Sprünge verkraftet: Skaliert es schnell genug? Laufen Warteschlangen über? Erholt es sich danach? Ein langsam ansteigender Lasttest würde genau diese Probleme nicht zeigen.

Richtig: Echte Nutzer lesen und überlegen zwischen den Klicks; ohne Denkzeit erzeugen 100 virtuelle Nutzer viel mehr Last als 100 echte

Ein virtueller Nutzer ohne Pausen entspricht oft zehn oder mehr echten. Ohne realistische Denkzeit sind die Ergebnisse entweder zu pessimistisch, oder man zieht falsche Schlüsse über die tatsächliche Nutzerzahl.

Richtig: Die JVM optimiert häufig genutzten Code erst zur Laufzeit (JIT), Caches und Verbindungspools füllen sich

Java-Anwendungen werden „warm“: Der JIT-Compiler übersetzt heißen Code in Maschinencode, Klassen werden geladen, Caches gefüllt. Messungen trennt man deshalb in Aufwärmphase und Messphase, sonst verfälscht der Kaltstart die Werte.

Richtig: Beim Datenbank-Verbindungspool

Die Ressource, die voll ausgelastet ist und vor der sich Warteschlangen bilden, begrenzt das ganze System. Mehr CPU würde hier nichts bringen. Ob der Pool zu klein ist oder Verbindungen zu lange gehalten werden, zeigt die nächste Untersuchung.

Richtig: Ein gemeinsam genutzter Engpass, z. B. die eine Datenbank, die alle Server verwenden

Horizontale Skalierung hilft nur, wenn der Engpass auf den Anwendungsservern liegt. Teilen sich alle dieselbe Datenbank, dieselbe Warteschlange oder dieselbe Sperre, verschiebt sich das Problem nur.

Richtig: 5

1000 / 200 = 5. In der Praxis plant man Reserve ein, z. B. einen Server mehr, damit der Ausfall eines Servers nicht sofort zur Überlast führt. Ob die Annahme „linear“ stimmt, muss ein Test zeigen (siehe Aufgabe zur Skalierung).

Richtig: Abfragen ohne passenden Index oder mit großen Ergebnismengen fallen bei 1.000 Einträgen nicht auf

Viele Performanceprobleme wachsen mit der Datenmenge, nicht mit der Nutzerzahl: fehlende Indizes, Sortierungen, N+1-Abfragen. Ein Lasttest ist nur so aussagekräftig wie die Ähnlichkeit seiner Umgebung zur Produktion.

Richtig: Die Daten landen im Cache, echte Nutzer fragen dagegen viele verschiedene Daten ab

Datenbank-, Anwendungs- und Betriebssystem-Caches liefern wiederholte Daten aus dem Speicher. In Produktion streuen die Zugriffe. Testdaten sollten deshalb aus einer großen, realistischen Menge gezogen werden.

Richtig: Die etwa 100 Anfragen, die während der Störung hätten starten sollen, werden nie gemessen; die Messung wirkt zu gut

Dieser Effekt heißt „Coordinated Omission“. Echte Nutzer warten nicht aufeinander, sie kommen weiter. Das Werkzeug misst eine langsame Anfrage, statt 100 betroffener Nutzer. Gute Werkzeuge senden nach festem Zeitplan oder korrigieren das rechnerisch.

Richtig: Einen Index auf die Spalte email anlegen

Ohne Index muss die Datenbank alle 4 Millionen Zeilen lesen. Mit Index findet sie den Eintrag in wenigen Schritten (ähnlich der Binärsuche). Der Ausführungsplan (EXPLAIN) zeigt, ob ein Index genutzt wird.

Richtig: Die Datenbank muss die übersprungenen Zeilen trotzdem durchgehen

OFFSET heißt „überspringe“, aber überspringen kostet Arbeit: Eine Million Zeilen werden gelesen und verworfen. Cursor-basiertes Blättern (WHERE id > letzte_id) ist dagegen für jede Seite gleich schnell.

Richtig: Das Bild verkleinern und komprimieren, z. B. in passender Größe als WebP

8 MB über eine mobile Verbindung dauern Sekunden, egal wie schnell der Server ist. Ein Titelbild braucht meist unter 300 KB. Die Entwicklerwerkzeuge des Browsers (Netzwerk-Tab) zeigen solche Brocken sofort.

Richtig: Pausen der Garbage Collection, bei denen die JVM kurz anhält

Ein regelmäßiges Muster, das alle Anfragen gleichzeitig trifft, passt gut zu GC-Pausen. Die GC-Logs zeigen es eindeutig. Abhilfen: weniger Objekte erzeugen, Heap passend wählen, einen Collector mit kurzen Pausen nutzen (G1, ZGC). Ein Backup wäre ebenfalls denkbar, deshalb Logs prüfen statt raten.

Richtig: Bei 500 gleichzeitigen Nutzern: 95 % der Anfragen unter 1 s, Fehlerquote unter 0,1 %

Zu einem prüfbaren Kriterium gehören Last, Antwortzeit als Perzentil und Fehlerquote. Ein System, das unter Last die Hälfte der Anfragen mit Fehler ablehnt, antwortet sehr schnell, besteht aber trotzdem nicht.

Richtig: 0,75

(60 + 30/2) / 100 = 75 / 100 = 0,75. 1,0 wäre perfekt, unter 0,5 gilt als inakzeptabel. Der Wert fasst Perzentile in eine Zahl zusammen, die sich auch Nicht-Technikern gut erklären lässt.