Wie viel Kapazität braucht Ihre Prüfungsplattform wirklich?

Wenn eine Prüfungsplattform ausfällt, tut sie das selten allmählich. Sie fällt im denkbar schlechtesten Moment aus — in den ersten Minuten einer Sitzung, wenn sich alle Kandidaten gleichzeitig anmelden — und die Folgen trägt die Institution, nicht der Anbieter.

Richtige Dimensionierung beginnt bei einer einzigen Zahl, die viele Spezifikationen nie nennen: der Spitzenparallelität.

Warum Einschreibungszahlen in die Irre führen

Die Gesamtzahl der Eingeschriebenen beschreibt Ihre Population, nicht Ihre Last. Eine Universität mit 40.000 Studierenden überschreitet womöglich nie 3.000 gleichzeitige Kandidaten, wenn Prüfungen über ein Semester verteilt sind. Eine Zulassungsstelle mit 10.000 Kandidaten im Jahr setzt möglicherweise alle in eine einzige nationale Sitzung.

Der zweite Fall ist trotz kleinerer Population weit anspruchsvoller — und eine an der Einschreibung bemessene Plattform wäre an der völlig falschen Zahl bemessen.

Die entscheidende Zahl berechnen

Rechnen Sie mit Ihrem Prüfungskalender, nicht mit dem Studierendenregister:

1. Finden Sie Ihre größte Einzelsitzung. Wie viele Kandidaten sind im selben Fenster angesetzt?
2. Addieren Sie die Anmeldespitze. Kandidaten kommen nicht gleichmäßig — die meisten authentifizieren sich in den ersten Minuten. Das ist meist die wahre Spitze.
3. Berücksichtigen Sie Überschneidungen. Laufen getrennte Prüfungen gleichzeitig? Dann addieren sich ihre Spitzen.
4. Rechnen Sie Reserve ein. Wachstum, Wiederholungsprüfungen und die Sitzung, die in eine ohnehin volle Woche verschoben wird.
5. Zählen Sie Aufsichten und Administratoren mit. Auch sie sind gleichzeitige Nutzer, oft mit schwereren Dashboards.

Das Ergebnis ist die Zahl, die Ihre Spezifikation nennen sollte — und auf die Anbieter antworten sollten.

Was Anbieter belegen sollten

Eine theoretische Obergrenze ist kein Beleg. Fragen Sie stattdessen:

• Welche höchste Parallelität haben Sie produktiv betrieben, und für welche Institution?
• Was geschah bei der Anmeldespitze in dieser Größenordnung?
• Wie verhält sich die Plattform bei Überlast — wird sie langsamer, stellt sie in eine Warteschlange, oder fällt sie aus?
• Können wir vor einer echten Sitzung einen Lasttest gegen unsere eigene Spitzenzahl fahren?

Die letzte Frage ist die nützlichste der Liste. Ein Anbieter, der sich in Ihrer Größenordnung sicher ist, stimmt einer Generalprobe zu; wer zögert, sagt Ihnen damit etwas.

Zum Vergleich: iTest ist für über 120.000 gleichzeitige Kandidaten und mehr als 2 Millionen Prüfungen jährlich ausgelegt und führt Ägyptens nationale medizinische Zulassungsprüfung (EMLE) durch — abgelegt von 9.397 Ärzten für den ägyptischen Gesundheitsrat und das Gesundheitsministerium.

Kapazität ist nicht nur eine Frage der Server

Parallelität belastet mehr als die Infrastruktur. In der Spitze brechen typischerweise drei andere Dinge zuerst:

• Authentifizierung — besonders wenn Single Sign-on über einen institutionellen Identity Provider läuft, der nie auf einen gleichzeitigen Ansturm lastgetestet wurde
• Integrationen — ein LMS oder Studierendenverwaltungssystem, das im falschen Moment in den kritischen Pfad gerät
• Aufsicht — Integritätsverarbeitung trägt eigene Last, und sie skaliert mit Kandidaten, nicht mit Prüfungen

Wo Systeme in dieser Größenordnung Daten austauschen müssen, zählt die Integrationsebene ebenso viel wie die Prüfungs-Engine. Intrazero löst das mit iMiddleware, das im ägyptischen nationalen LMS-Programm über 500 staatliche Universitätsfakultäten zusammenführt.

Dimensionierung und Betriebsmodell hängen zusammen

Verlangt Ihre Aufsichtsbehörde On-Premise-Betrieb, wird Ihre Spitzenparallelität zu einer Infrastrukturanforderung, die Sie selbst erfüllen müssen. Ermitteln Sie die Zahl vor der Modellwahl, denn sie bestimmt, was Sie bereitstellen müssen.

iTest unterstützt Cloud, On-Premise und Hybrid, und die Parallelitätszahl sollte gegen das Modell vereinbart werden, das Sie tatsächlich betreiben — nicht gegen den Cloud-Benchmark des Anbieters, wenn Sie lokal betreiben wollen.

Kurz gefasst

Nennen Sie die Spitzenparallelität, nicht die Einschreibung. Rechnen Sie die Anmeldespitze ein. Fragen Sie, was der Anbieter produktiv betrieben hat, statt was das Datenblatt behauptet. Und proben Sie mit Ihrer echten Spitze, bevor die Sitzung ansteht, auf die es ankommt.