Performance
Wie schnell sind CoreEngine und CoreEngineClaim wirklich? Beide Plugins werden mit automatisierten Benchmark-Tests vermessen, die bei jedem Testlauf mitlaufen. Diese Seite fasst die Ergebnisse zusammen und ordnet sie ein.
Zur Einordnung: Ein Minecraft-Server hat pro Tick 50 Millisekunden Zeit (20 Ticks pro Sekunde). Alles, was auf dem Haupt-Thread passiert, muss in dieses Budget passen. CoreEngine schreibt deshalb grundsätzlich nie auf dem Haupt-Thread in die Datenbank, sondern auf einem eigenen Hintergrund-Thread.
Messsystem: AMD Ryzen 9 9950X, Windows 11, Java 25. Auf anderer Hardware verschieben sich die absoluten Zahlen, die Größenordnungen bleiben gleich.
CoreEngine #
| Messung | Durchsatz | Dauer pro Vorgang |
|---|---|---|
Kontostand lesen (/balance, Placeholders) | 61 Millionen/s | 0,016 µs |
| Geld-Transaktion inklusive Speichern auf der Platte | 489/s | 2,0 ms |
| Einzelner Datenbank-Schreibvorgang | 297/s | 3,4 ms |
| Einzelner Datenbank-Lesevorgang | 126.800/s | 7,9 µs |
/baltop bei 10.000 Konten (schlechtester Fall, ohne Cache) | 590/s | 1,7 ms |
Zeitangaben parsen (2h30m bei Mutes/Bans) | 1,7 Millionen/s | 0,59 µs |
Was das bedeutet:
- Kontostände lesen ist praktisch gratis. Selbst wenn jedes Event auf dem Server einen Kontostand abfragen würde, wäre das nicht messbar.
- Geld-Transaktionen bremsen den Server nicht. Auf dem Haupt-Thread kostet eine Einzahlung weniger als eine Mikrosekunde, das eigentliche Speichern passiert im Hintergrund. Die 489 Transaktionen pro Sekunde sind die Grenze des Hintergrund-Threads, das entspricht rund 29.000 Geld-Transaktionen pro Minute Dauerlast.
/baltopist auch bei 10.000 Konten unkritisch, das Ergebnis wird zusätzlich 30 Sekunden zwischengespeichert.
CoreEngineClaim #
Der wichtigste Pfad des Claim-Plugins ist die Frage "in welchem Claim liegt diese Position?". Sie wird bei praktisch jedem Schutz-Event gestellt: Block abbauen oder platzieren, Kiste öffnen, PvP-Schlag, Redstone, Kolben. Gemessen wurde gegen eine Welt mit 2.000 Claims, davon 100 mit je 5 Subdivisions:
| Messung | Durchsatz | Dauer pro Vorgang |
|---|---|---|
| Position liegt in einem Claim | 183.500/s | 5,5 µs |
| Position liegt in einer Subdivision | 64.600/s | 15,5 µs |
| Position liegt in der Wildnis | 366.000/s | 2,7 µs |
| Claim erstellen inklusive Überlappungs-Prüfung | 6.650/s | 150 µs |
Was das bedeutet:
- Der Schutz-Check ist extrem schnell. Selbst im teuersten Fall passen über 3.000 Prüfungen in einen einzigen Tick, bevor auch nur 1 ms des 50-ms-Budgets verbraucht ist. Ein Server mit 100 Schutz-Events pro Tick (das wäre bereits sehr viel) verbraucht dafür unter 0,2 % des Budgets.
- Die Wildnis ist der billigste Fall, gut so, denn dort passieren auf Survival-Servern die meisten Events. Die Kosten wachsen dabei nicht mit der Gesamtzahl der Claims, sondern nur mit den Claims im jeweiligen Chunk.
- Claim-Erstellung fühlt sich verzögerungsfrei an, auch wenn gegen tausende bestehende Claims auf Überlappung geprüft wird.
Fazit #
Hinweis: Beide Plugins haben keinen Pfad, der den Server-Tick gefährdet. Alles Häufige läuft im Mikrosekunden-Bereich aus dem Speicher, alles Langsame (Festplatten-Schreibvorgänge) läuft auf einem eigenen Thread. Die Datenstrukturen skalieren: 2.000 Claims oder 10.000 Konten ändern an den Antwortzeiten praktisch nichts.