OBS/Adminhilfe/OBSAdministration/Protokolle/SpeedtestProto: Unterschied zwischen den Versionen

Aus OBS Wiki
Zur Navigation springen Zur Suche springen
Für diese Seite wurde eine Zugriffsbeschränkung eingerichtet. Falls du diese Nachricht siehst, bist du nicht berechtigt, diese Seite einzusehen.
(Die Seite wurde neu angelegt: „Hello from United States. I'm glad to be here. My first name is Angelina. <br>I live in a city called Burbank in south United States.<br>I was also born in Bur…“)
 
KKeine Bearbeitungszusammenfassung
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1: Zeile 1:
Hello from United States. I'm glad to be here. My first name is Angelina. <br>I live in a city called Burbank in south United States.<br>I was also born in Burbank 39 years ago. Married in April year 2007. I'm working at the post office.<br><br>Here is my page ... [http://daltonwwlganyxcw.sosblogs.com panni in microfibra]
{{ZugriffOBS}}
[[Kategorie:Adminhilfe]]
 
= Speedtest-Protokoll (SPEEDTEST_PROTO) =
 
Die Tabelle '''SPEEDTEST_PROTO''' speichert die Ergebnisse des OBS-Datenbank-Speedtests.
Sie wird '''wöchentlich sonntags''' automatisch durch die Garbage Collection befüllt
(siehe {{{!}} [[Garbage_Collection]]) und liefert eine langfristige Historie aller
Messungen für spätere Versions- oder Hardwarevergleiche.
 
Pro Lauf wird '''je Block''' eine Zeile geschrieben. Alle Zeilen eines Laufs teilen sich
die gleiche '''SPT_RUNID''', so dass sich ein kompletter Lauf einfach filtern lässt.
Die '''Retention ist unbegrenzt''' &ndash; Einträge werden nie automatisch gelöscht.
 
== Felder der Tabelle ==
 
{| class="wikitable"
! Feld !! Typ !! Breite !! Bedeutung
|-
| SPT_RUNID      || C || 14  || Lauf-Kennung im Format <code>yyyymmddhhnnss</code>. Alle Zeilen eines Laufs haben die gleiche RunID.
|-
| SPT_DATUM      || D || 4  || Startdatum des Laufs.
|-
| SPT_ZEIT      || C || 8  || Startuhrzeit im Format <code>HH:MM:SS</code>.
|-
| SPT_HOST      || V || 60  || Rechnername (<code>COMPUTERNAME</code>), auf dem der Test lief.
|-
| SPT_DBVERSION  || V || 30  || Server-Version der DB (z. B. <code>MySQL 8.4.8</code>) oder <code>CPU</code> beim CPU-Test.
|-
| SPT_BLOCK      || V || 40  || Name des Test-Blocks (siehe Liste unten).
|-
| SPT_ITER      || N || 10,0 || Anzahl der Iterationen in diesem Block.
|-
| SPT_MIN_MS    || N || 12,3 || Kleinste gemessene Zeit pro Iteration in Millisekunden.
|-
| SPT_AVG_MS    || N || 12,3 || Arithmetisches Mittel der Iterations-Zeiten in ms.
|-
| SPT_MED_MS    || N || 12,3 || Median der Iterations-Zeiten in ms.
|-
| SPT_MAX_MS    || N || 12,3 || Längste gemessene Zeit pro Iteration in ms.
|-
| SPT_STD_MS    || N || 12,3 || Standardabweichung der Iterations-Zeiten in ms.
|-
| SPT_OPSSEC    || N || 10,0 || Durchsatz in Operationen/Sekunde &ndash; nur beim Concurrency-Block gefüllt, sonst 0.
|-
| SPT_STATUS    || V || 30  || <code>OK</code>, <code>FAIL</code> oder <code>SKIPPED</code> (siehe Status-Werte).
|-
| SPT_INFO      || V || 200 || Zusatzinformation (z. B. Grund für SKIPPED, Fehlermeldung, Concurrency-Worker-Anzahl).
|-
| SPT_DURATION_S || N || 8,0  || Gesamtdauer des Laufs in Sekunden. In jeder Zeile eines Laufs gleich.
|-
| SYS_UID        || C || 10  || Technische UID des Datensatzes (vom OBS-Framework vergeben).
|-
| SYS_DATE      || D || 4  || Anlagedatum des Datensatzes (AUTODATE).
|}
 
== Mögliche Werte für SPT_BLOCK ==
 
Jeder Eintrag in dieser Spalte entspricht einem abgegrenzten Messblock. Die folgenden
Blöcke werden beim wöchentlichen DB-Speedtest geschrieben:
 
{| class="wikitable"
! Block !! Was wird gemessen
|-
| <code>roundtrip_seek_pk</code>      || Zeit für einen einzelnen Seek per Primärschlüssel &ndash; Grundlast Netzwerk + Index-Lookup.
|-
| <code>blob_write</code>            || Schreiben eines ca. 250 KB großen BLOBs pro Iteration.
|-
| <code>blob_read_verify</code>      || Lesen und Verifizieren der zuvor geschriebenen BLOBs.
|-
| <code>insert_single_commit</code>  || Einzelinserts mit individuellem COMMIT &ndash; typische Auftragsposition.
|-
| <code>insert_batch_1000</code>      || Batch-Insert von 1000 Zeilen pro Lauf (mehrere Durchläufe).
|-
| <code>seek_indexed</code>          || Seek auf indiziertem VARCHAR-Feld.
|-
| <code>seek_unindexed</code>        || Seek ohne Index &ndash; ergibt Full-Table-Scan.
|-
| <code>aggregate_count_sum</code>    || Aggregat-Query (COUNT + SUM) über die Speed-Tabellen.
|-
| <code>concurrent_insert_Nt</code>  || Parallele Inserts mit ''N'' Worker-Threads über N_CONCURRENCY_SECS Sekunden. Standard <code>concurrent_insert_4t</code>. Hier sind die Zeitspalten '''leer''' (-1), stattdessen wird der Durchsatz in <code>SPT_OPSSEC</code> gespeichert.
|}
 
Wird der CPU-Test separat aufgerufen, stehen zusätzlich diese Blöcke im Report (nicht in
der Tabelle):
<code>cpu_float</code>, <code>cpu_int</code>, <code>cpu_mem_structures</code>,
<code>cpu_mem_alloc</code>, <code>cpu_hash_md5</code>.
 
== Status-Werte ==
 
{| class="wikitable"
! Wert !! Bedeutung
|-
| <code>OK</code>      || Block regulär gemessen, keine Ausnahmen.
|-
| <code>FAIL</code>    || Block lief in eine Exception; Details in <code>SPT_INFO</code>.
|-
| <code>SKIPPED</code> || Block wurde ausgelassen, weil das Zeitbudget (<code>N_BUDGET_MAX_SECS</code>, Standard 900 s) überschritten war. Die Zeitspalten sind dann -1.
|}
 
== Automatische Ausführung ==
 
* Ausführung erfolgt '''nur sonntags''' durch <code>GarbageSpeedTest</code> innerhalb der Garbage Collection.
* Es wird ausschließlich der '''DB-Speedtest''' automatisch ausgeführt &ndash; der CPU-Test nicht.
* Parallele Starts werden über die Semaphore <code>OBS_DB_Speed</code> verhindert; ein manueller Menü-Aufruf und der Garbage-Lauf schließen sich gegenseitig aus.
* Schreibfehler in die Tabelle '''kippen nicht''' den Rückgabewert des Tests &ndash; sie landen nur als Hinweis im ausgegebenen Report-Text (<code>note=proto_write_failed&nbsp;…</code>).
* Manuelle Aufrufe im OBS-Menü schreiben '''nicht''' in die Tabelle (nur Report-Ausgabe); erst der Parameter <code>lWriteProto=True</code> aktiviert das Persistieren.
 
== Beispiel-Abfragen ==
 
Trend eines einzelnen Blocks über die Zeit:
 
<pre>
SELECT spt_datum, spt_zeit, spt_avg_ms, spt_max_ms
  FROM SPEEDTEST_PROTO
WHERE spt_block = 'roundtrip_seek_pk'
ORDER BY spt_datum, spt_zeit;
</pre>
 
Letzten Lauf komplett anzeigen:
 
<pre>
SELECT spt_block, spt_iter, spt_avg_ms, spt_max_ms, spt_opssec, spt_status
  FROM SPEEDTEST_PROTO
WHERE spt_runid = (SELECT MAX(spt_runid) FROM SPEEDTEST_PROTO)
ORDER BY spt_block;
</pre>
 
Alle Fehlschläge der letzten 3 Monate:
 
<pre>
SELECT spt_runid, spt_host, spt_block, spt_info
  FROM SPEEDTEST_PROTO
WHERE spt_status IN ('FAIL','SKIPPED')
  AND spt_datum >= CURDATE() - INTERVAL 90 DAY
ORDER BY spt_datum DESC;
</pre>
 
== Hinweise ==
 
* '''Vergleichbarkeit nur bei gleicher Hardware:''' Messwerte sind absolute Millisekunden und damit nur innerhalb desselben Hosts und derselben DB-Version direkt vergleichbar. Bei Serverwechsel oder DB-Upgrades wird ein Bruch in den Trends sichtbar &ndash; Kontext dafür liefert <code>SPT_HOST</code> / <code>SPT_DBVERSION</code>.
* '''Concurrency-Block hat keine ms-Werte:''' <code>SPT_MIN_MS</code>…<code>SPT_STD_MS</code> sind hier -1; für die Beurteilung zählt <code>SPT_OPSSEC</code> (Operationen/Sekunde über die Laufdauer).
* '''SKIPPED nicht als Warnung verstehen:''' Es bedeutet nur, dass das globale Zeitbudget bereits überschritten war. Der Gesamtlauf bleibt dann trotzdem <code>OK</code>, wenn kein Fehler auftrat.
* '''Laufende Belastung:''' Ein Lauf dauert üblicherweise etwa 60&ndash;120 s. Während dieser Zeit laufen echte Schreib-/Lese-Zyklen gegen die Testtabellen <code>SPEEDBLOB</code>, <code>SPEEDTABEL</code> und <code>SPEEDTABELVC</code> &ndash; das ist spürbare Last, aber zeitlich begrenzt und wird durch die Sonntags-Ausführung am sensiblen Einsatzbetrieb vorbeigelegt.
* '''Cleanup:''' Die Speed-Tabellen werden vor und nach dem Lauf geZAPt. Bleiben dort im Fehlerfall Zeilen stehen, sind diese ignorierbar &ndash; sie werden beim nächsten Lauf erneut entfernt.
* '''Keine manuelle Löschung nötig:''' Das Wachstum ist gering (~10 Zeilen pro Woche, also einige KB pro Jahr). Die Historie bleibt dauerhaft erhalten.

Aktuelle Version vom 23. April 2026, 12:43 Uhr

Dies ist eine zugriffsgeschützte Seite.


Admin-Hilfe

OBS-Administration / Installation
kundenspezifische Anpassungen
Shop-Administration
Minerva (AI)

Speedtest-Protokoll (SPEEDTEST_PROTO)

Die Tabelle SPEEDTEST_PROTO speichert die Ergebnisse des OBS-Datenbank-Speedtests. Sie wird wöchentlich sonntags automatisch durch die Garbage Collection befüllt (siehe {| Garbage_Collection) und liefert eine langfristige Historie aller Messungen für spätere Versions- oder Hardwarevergleiche.

Pro Lauf wird je Block eine Zeile geschrieben. Alle Zeilen eines Laufs teilen sich die gleiche SPT_RUNID, so dass sich ein kompletter Lauf einfach filtern lässt. Die Retention ist unbegrenzt – Einträge werden nie automatisch gelöscht.

Felder der Tabelle

Feld Typ Breite Bedeutung
SPT_RUNID C 14 Lauf-Kennung im Format yyyymmddhhnnss. Alle Zeilen eines Laufs haben die gleiche RunID.
SPT_DATUM D 4 Startdatum des Laufs.
SPT_ZEIT C 8 Startuhrzeit im Format HH:MM:SS.
SPT_HOST V 60 Rechnername (COMPUTERNAME), auf dem der Test lief.
SPT_DBVERSION V 30 Server-Version der DB (z. B. MySQL 8.4.8) oder CPU beim CPU-Test.
SPT_BLOCK V 40 Name des Test-Blocks (siehe Liste unten).
SPT_ITER N 10,0 Anzahl der Iterationen in diesem Block.
SPT_MIN_MS N 12,3 Kleinste gemessene Zeit pro Iteration in Millisekunden.
SPT_AVG_MS N 12,3 Arithmetisches Mittel der Iterations-Zeiten in ms.
SPT_MED_MS N 12,3 Median der Iterations-Zeiten in ms.
SPT_MAX_MS N 12,3 Längste gemessene Zeit pro Iteration in ms.
SPT_STD_MS N 12,3 Standardabweichung der Iterations-Zeiten in ms.
SPT_OPSSEC N 10,0 Durchsatz in Operationen/Sekunde – nur beim Concurrency-Block gefüllt, sonst 0.
SPT_STATUS V 30 OK, FAIL oder SKIPPED (siehe Status-Werte).
SPT_INFO V 200 Zusatzinformation (z. B. Grund für SKIPPED, Fehlermeldung, Concurrency-Worker-Anzahl).
SPT_DURATION_S N 8,0 Gesamtdauer des Laufs in Sekunden. In jeder Zeile eines Laufs gleich.
SYS_UID C 10 Technische UID des Datensatzes (vom OBS-Framework vergeben).
SYS_DATE D 4 Anlagedatum des Datensatzes (AUTODATE).

Mögliche Werte für SPT_BLOCK

Jeder Eintrag in dieser Spalte entspricht einem abgegrenzten Messblock. Die folgenden Blöcke werden beim wöchentlichen DB-Speedtest geschrieben:

Block Was wird gemessen
roundtrip_seek_pk Zeit für einen einzelnen Seek per Primärschlüssel – Grundlast Netzwerk + Index-Lookup.
blob_write Schreiben eines ca. 250 KB großen BLOBs pro Iteration.
blob_read_verify Lesen und Verifizieren der zuvor geschriebenen BLOBs.
insert_single_commit Einzelinserts mit individuellem COMMIT – typische Auftragsposition.
insert_batch_1000 Batch-Insert von 1000 Zeilen pro Lauf (mehrere Durchläufe).
seek_indexed Seek auf indiziertem VARCHAR-Feld.
seek_unindexed Seek ohne Index – ergibt Full-Table-Scan.
aggregate_count_sum Aggregat-Query (COUNT + SUM) über die Speed-Tabellen.
concurrent_insert_Nt Parallele Inserts mit N Worker-Threads über N_CONCURRENCY_SECS Sekunden. Standard concurrent_insert_4t. Hier sind die Zeitspalten leer (-1), stattdessen wird der Durchsatz in SPT_OPSSEC gespeichert.

Wird der CPU-Test separat aufgerufen, stehen zusätzlich diese Blöcke im Report (nicht in der Tabelle): cpu_float, cpu_int, cpu_mem_structures, cpu_mem_alloc, cpu_hash_md5.

Status-Werte

Wert Bedeutung
OK Block regulär gemessen, keine Ausnahmen.
FAIL Block lief in eine Exception; Details in SPT_INFO.
SKIPPED Block wurde ausgelassen, weil das Zeitbudget (N_BUDGET_MAX_SECS, Standard 900 s) überschritten war. Die Zeitspalten sind dann -1.

Automatische Ausführung

  • Ausführung erfolgt nur sonntags durch GarbageSpeedTest innerhalb der Garbage Collection.
  • Es wird ausschließlich der DB-Speedtest automatisch ausgeführt – der CPU-Test nicht.
  • Parallele Starts werden über die Semaphore OBS_DB_Speed verhindert; ein manueller Menü-Aufruf und der Garbage-Lauf schließen sich gegenseitig aus.
  • Schreibfehler in die Tabelle kippen nicht den Rückgabewert des Tests – sie landen nur als Hinweis im ausgegebenen Report-Text (note=proto_write_failed …).
  • Manuelle Aufrufe im OBS-Menü schreiben nicht in die Tabelle (nur Report-Ausgabe); erst der Parameter lWriteProto=True aktiviert das Persistieren.

Beispiel-Abfragen

Trend eines einzelnen Blocks über die Zeit:

SELECT spt_datum, spt_zeit, spt_avg_ms, spt_max_ms
  FROM SPEEDTEST_PROTO
 WHERE spt_block = 'roundtrip_seek_pk'
 ORDER BY spt_datum, spt_zeit;

Letzten Lauf komplett anzeigen:

SELECT spt_block, spt_iter, spt_avg_ms, spt_max_ms, spt_opssec, spt_status
  FROM SPEEDTEST_PROTO
 WHERE spt_runid = (SELECT MAX(spt_runid) FROM SPEEDTEST_PROTO)
 ORDER BY spt_block;

Alle Fehlschläge der letzten 3 Monate:

SELECT spt_runid, spt_host, spt_block, spt_info
  FROM SPEEDTEST_PROTO
 WHERE spt_status IN ('FAIL','SKIPPED')
   AND spt_datum >= CURDATE() - INTERVAL 90 DAY
 ORDER BY spt_datum DESC;

Hinweise

  • Vergleichbarkeit nur bei gleicher Hardware: Messwerte sind absolute Millisekunden und damit nur innerhalb desselben Hosts und derselben DB-Version direkt vergleichbar. Bei Serverwechsel oder DB-Upgrades wird ein Bruch in den Trends sichtbar – Kontext dafür liefert SPT_HOST / SPT_DBVERSION.
  • Concurrency-Block hat keine ms-Werte: SPT_MIN_MSSPT_STD_MS sind hier -1; für die Beurteilung zählt SPT_OPSSEC (Operationen/Sekunde über die Laufdauer).
  • SKIPPED nicht als Warnung verstehen: Es bedeutet nur, dass das globale Zeitbudget bereits überschritten war. Der Gesamtlauf bleibt dann trotzdem OK, wenn kein Fehler auftrat.
  • Laufende Belastung: Ein Lauf dauert üblicherweise etwa 60–120 s. Während dieser Zeit laufen echte Schreib-/Lese-Zyklen gegen die Testtabellen SPEEDBLOB, SPEEDTABEL und SPEEDTABELVC – das ist spürbare Last, aber zeitlich begrenzt und wird durch die Sonntags-Ausführung am sensiblen Einsatzbetrieb vorbeigelegt.
  • Cleanup: Die Speed-Tabellen werden vor und nach dem Lauf geZAPt. Bleiben dort im Fehlerfall Zeilen stehen, sind diese ignorierbar – sie werden beim nächsten Lauf erneut entfernt.
  • Keine manuelle Löschung nötig: Das Wachstum ist gering (~10 Zeilen pro Woche, also einige KB pro Jahr). Die Historie bleibt dauerhaft erhalten.