Mit dem Umzug einher gab es zwei kleine Änderungen, zum einen wurde der Blog auf WordPress Version 2.8.6 aktualisiert, zum anderen wurden Memcache als Daten-Cache und APC als PHP-Bytecache integriert. Dadurch sollte der Server Inhalte nun schneller ausliefern. Ich habe vor, hier noch etwas mehr Zeit zu investieren und durch Profiling herauszubekommen, wo man sich noch verbessern kann.

Also immer dran bleiben!

Mal im Ernst: Kennt jemand eine langsamere Seite als msdn? Dagegen ist selbst WordPress ein Fest in Lichtgeschwindigkeit.

Was ist denn Memcache?

Memcache ist ein Dienst, der es erlaubt, Daten im Arbeitsspeicher vorzuhalten. Daneben erlaubt er es auch noch, dies über mehrere Server zu verteilen, also ein richtiges Speicher-Netzwerk aufzubauen. Und Arbeitsspeicher ist eine der schnellsten Zugriffsformen auf Daten, die wir zur Zeit haben. Memcache kann durch das Zwischenspeichern von Daten, die sonst mühsam aus anderer Stelle geholt werden müssen, das Leben leichter und angenehm schneller gestalten.

Dazu muss man sagen, dass ja Webanwendungen von Seitenaufruf zu Seitenaufruf jeweils neu initialisiert werden müssen. Als Benutzer in einer Sitzung (Session) ist einem das oft nicht bewusst, aber es kostet den Server bei jedem Klick eine entsprechende Zeit, die Session zu restaurieren und die Daten wieder so herzustellen, damit die nächste Aktion ausgeführt werden kann. Die Sessions werden in einer Datei auf dem Server abgelegt. Das heißt also auch Festplattenaktivität pro Klick. Das ist doof. Noch dümmer, dass man nicht wirklich viel in solch eine Session legen kann und sollte. Je größer das Session-File, desto langsamer wird jeder einzelne Aufruf. Dinge also, die nicht wirklich essentiell sind, holt man also immer wieder neu aus einer Datenbank oder anderen Quellen.

Daneben gibt es noch Session-unabhängige Daten. Bei einem News-Portal also die aktuellen Beiträge zum Beispiel. Doch die sollte man nicht jedem der Millionen von Nutzern in die Session legen. Dabei sind diese ständig gefragt, was macht man also damit? Memcache ist hier die richtige Lösung. Mit Memcache lassen sich diese nutzerunabhängigen Daten genau einmal speichern, aber für jeden Nutzer in hoher Geschwindigkeit bereitstellen. Das macht richtig Spaß.

Was geht in Memcache rein?

Das Beste ist: Memcache bildet nur eine simple Zuweisung von Key-Value-Paaren ab. Unter einer Zeichenkette als Schlüssel, der maximal 250 Zeichen Länge betragen darf, werden einfache Zeichenketten als Werte hinterlegt. Die Werte dürfen maximal 1 MB Größe haben. Was man darin speichert, ist tatsächlich vollkommen egal. Man kann also gezielt eine Datenbank beschleunigen oder aber auch Template-Engines entlasten, also ganze HTML-Vorlagen ablegen, vielleicht auch schon komplett mit allen Inhalten gerendert. Ebenso lassen sich die Einträge unabhängig von deren Nutzung befüllen, zum Beispiel nachts, wenn die Last der Server geringer ist. Tagsüber stehen dann z.B. aggregierte Daten zum schnellen Abruf bereit.

Die PHP-Schnittstelle ist dazu mit einer automatischen Serialisierung implementiert. Man kann also einfach komplexere Objekte und Arrays einfach hineinwerfen – und so kommen sie auch heraus. Einzig und allein Pointer wie Dateizeiger oder auch (Datenbank-)Verbindungen sollte man nicht hineinwerfen, denn Ressourcen können im Allgemeinen nicht richtig wiederhergestellt werden. Jeder Eintrag kann dabei on-the-fly mit zlib komprimiert werden, sollte es sich um größere Datenmengen handeln, um im 1-MB-Bereich zu bleiben oder einfach aus Speichergründen. Der Dienst memcached wird außerdem mit einer Option -m für die Gesamtspeichergröße

/usr/local/bin/memcached -d -m <Anzahl der MB> -p 11211 -l 127.0.0.1 -u nobody

gestartet, sodass bei -m 2048 maximal 2 GB des Arbeitsspeichers belegt werden. Nicht zuletzt wird beim Zwischenspeichern ein Zeitlimit gesetzt, wie lange der Cache-Eintrag gültig sein soll.

Anwendung am Beispiel www.ebrosia.de

Zunächst habe ich ein Profiling unserer Startseite gemacht. Die sollte wohl sehr häufig aufgerufen werden. Insgesamt bietet allein diese Seite Anlass für über 100 Datenbank-Abfragen, wenn man alles streng nimmt. Also ist das mein erstes Optimierungsgebiet gewesen. Es gibt natürlich Abfragen, die man besser nicht zwischenspeichert, wie zum Beispiel den Warenkorb des Benutzers – der sollte immer auf die Sekunde aktuell sein. Die Zusammenfassung des Warenkorbs (x Artikel mit y Gesamtpreis) wandert also am besten in die Session: Verbraucht nicht viel Platz, ist nutzerabhängig und wird bei einer Änderung am Warenkorb neu errechnet, also eher selten.

Bei der Entscheidung, ob ganze Templates optimiert werden sollen, habe ich mich dagegen entschieden: Die Mehrzahl der Seiten bietet für eingeloggte Nutzer individualisierte Inhalte, dazu sind die Templates nicht wirklich die Zeitfresser, da reines HTML und PHP zum Einsatz kam, also keine Layout-Engine verwendet wird. Die Seiten leben eher von den kleinen Abfragen an die Datenbank. Hier und da geht es um Links zu einem Artikel, um einen Preis, einen Artikelnamen. Speziell zu Wein kamen noch das Land, ein Gebiet oder eine Rebsorte hinzu.

Wenn man einen Shop betreibt, dann sind die Produktdaten das A und O, gerade bei etwa 1000 Artikeln. In fast jeder Shop-Seite, besonders auf der Startseite, kommen mehrere, auch wechselnde Artikel vor. Jeder Artikel hat einen Namen, einen Preis, einen Rabatt und eine Lieferbarkeit. Diese Daten werden eventuell mehrfach pro Sekunde abgerufen, aber vielleicht nur einmal im Monat geändert, zum Beispiel bei einer Rabatt-Aktion. Setzt man hier ein Zeitlimit von 10-20 Minuten an, sollten also geschätzte 90% der Aufrufe mit Memcache abgefangen werden, ohne dass die Aktualität leidet. Ich habe mich für ein kurzes Zeitfenster von 10 Minuten entschieden, um im Fehlerfall flexibler zu bleiben.

Also habe ich dort angesetzt. Memcache bildete eine Art Zwischenschicht zwischen dem Shop als Gestaltung und dem Datenbank-Backend. Letztlich konnte ich so mit nur einer kleinen Memcache-Implementierung im Backend gleich sehr viele Shop-Seiten verbessern, die auf die optimierten Funktionen mit den SQL-Abfragen zugreifen. Mit der Zwischenspeicherung von Preisen, Rabatten, Namen von Artikeln und Kategorien habe ich die Startseite auf ein durchschnittliches Volumen von etwa 5 SQL-Anfragen gedrückt. Diese Anfragen gehen auf die stetige Erneuerung von Cache-Einträgen wie auch das Rotieren von Produkten in Teasern zurück. Letztlich betrug die Zeit der Auslieferung der Startseite nur noch 35-50 Millisekunden (PHP-Start bis PHP-Ende). Seiten ohne SQL-Inhalte bewegten sich gleichen Zeitrahmen. Man konnte demnach davon ausgehen, dass das Caching die Belastung des MySQL-Servers auf ein Minimum reduziert hatte.

Im zweiten Schritt ging es dann an Artikel- und Kategorie-Seiten. Diese waren schon weitgehend durch den vorigen Schritt entlastet. Es waren nur noch wenige Handgriffe zu tun, um auch hier an die gleichen Rendering-Zeiten zu gelangen. In Frieden ließ ich den individuellen Konto-Bereich der Kunden. Hier wäre auch das Optimierungspotenzial geringer. Mit dem investierten Aufwand bin ich bereits weit genug gekommen für eine erste Runde.

Rollout auf dem Webserver

Libevent installiert und memcache kurz kompiliert, schon konnte es losgehen. Der Dienst startete angenehm einfach. Das PHP-Modul ist mit einem einfach phpize, configure und make ebenso leicht aufgesetzt. Jetzt nur noch das Modul in der php.ini fest eingetragen und nach einem kurzen Neustart des Apache sagte mir ein Testskript “Ja, es ist angerichtet.”

Der Shop wurde synchronisiert, und schwupps, kamen erste Ergebnisse im Cache an. Das Gefühl eines schnelleren Arbeitens war wirklich omnipräsent, das fühlte sich gleich gut an. Nach einigen Stunden Laufzeit hatte Memcache eine Trefferquote von etwa 87% zu verzeichnen, und die Last auf dem DB-Server war damit drastisch gefallen. An die Optimierung weiterer Bereiche kann nun Schritt für Schritt herangegangen werden. Nagios zeichnet flachere Kurven, und der Admin ist zufrieden. Jetzt kann Weihnachten kommen.

Das ist allerdings nicht ganz so easy, wenn sich die Daten des Satzes in verschiedenen Tabellen befinden. Also muss man die sich mühevoll zusammenklauben. Bei uns im Shop sind es eigentlich nur eine Handvoll Tabellen: Der Artikeleintrag in der Warenwirtschaft, die Varianten, die Preise, Rabatte, Shop-Eintrag, Shop-Texte und Shop-Fotos.

Die Einträge wurden aus eben diese Tabellen zusammengesucht. Aus Performance-Gründen bieten sich hier Stored Procedures an:
DELIMITER ‘$’;
CREATE FUNCTION f_getModified(…xyz…) RETURNS Datetime READS SQL DATA
BEGIN
DECLARE last DATETIME;
DECLARE cur DATETIME;
SELECT Timestamp INTO last FROM Tbl_XYZ INTO last WHERE xyz;
SELECT Timestamp INTO cur FROM Tbl_XYZ cur WHERE xyz;
SET last = IF(cur > last, cur, last);
…
RETURN last;
END$
DELIMITER ‘;’$

Natürlich schrumpft die Performance bei zunehmender Fragmentierung der Produktdaten erheblich, da die Berechnungskosten linear steigen. Aus diesem Grund habe ich überlegt, die Tabellen über INNER JOINS zu verknüpfen, und die Zeitstempel zunächst in einem Ritt zu holen:
DELIMITER ‘$’;
CREATE FUNCTION f_getModified(…xyz…) RETURNS Datetime READS SQL DATA
BEGIN
DECLARE last DATETIME;
DECLARE cur DATETIME;
SELECT a.Timestamp, b.Timestamp INTO last,cur FROM Tbl_XYZ a INNER JOIN TblXYZ b ON a.x=b.x AND a.y=b.y WHERE xyz;
SET last = IF(cur > last, cur, last);
RETURN last;
END$
DELIMITER ‘;’$

Auf meine 7 Tabellen angewendet, gibt das immerhin einen 10%-igen Performance-Schub. Nicht unerheblich, aber trotzdem nicht der Bringer. Anfangs waren es über 50% Geschwindigkeitsvorteil, als ich mit einfachen INNER JOINS über die ersten Tabellen arbeitete. Doch da es nicht immer entsprechende Einträge geben muss, ist man hier und da gezwungen, ein paar LEFT JOIN einzusetzen, welche als OUTER JOIN natürlich langsamer sind.

Ein weiteres Problem ist, dass nicht alle Tabellen einen Eintrag pro Produkt bieten, d.h. an dieser Stelle sind Sub-SELECTS vonnötigen, die den Zeitstempel über MAX(Timestamp) zunächst in der Ziel-Tabelle aggregieren, bevor der INNER JOIN einsetzt.

Letztendlich hatte ich bei einer entsprechend aufbereiteten Seite doch eher dazu tendiert, die bereits mit dem PHP-Script ausgelesenen Timestamps und die fehlenden Stempel per Hash-Scan zu ergänzen. An dieser Stelle konnte ich die Kosten für die Zeitstempel auf 20% der Procedure-Kosten drücken – allerdings ist diese Vorgehensweise nicht an allen Stellen die beste.

Doch bietet eine Seite nicht auch noch mehr? FAQs? Bewertungen? Mitkaufartikel? Hat sich die Seite nicht auch deswegen geändert, weil hier und da ein Eintrag dazugekommen ist? Was passiert, wenn sich eine Seite geändert hat, weil ein Eintrag wegfiel? Gar nicht so einfach, und ich möchte gern wissen, wie das “große” Shops so machen…Wer Ideen hat, ist zum Posten gerne eingeladen!

Außerdem verwenden wir für 90% unserer Daten MyISAM-Tabellen, die sich jedoch nur schwer mit Postgres vergleichen lassen. Da sollte man schon InnoDB verwenden und auf dieselben Features zurückgreifen, zum Beispiel Transaktionen, Referentielle Integrität oder Row Level Locking, welches ich mal mit zeilenbasiertes Sperren übersetzen möchte.

Es gibt jedoch eine Menge Sites, die aus ihren eigenen Tests die eine oder andere Datenbank stets als schneller evaluiert haben, zB Drupal. Man sollte da einfach mal nach “MySQL Postgres” googlen. Man kann dabei aber schnell ins religiöse Halblicht reingezogen werden. Die Tests werden meist von Advocacies und Flamewars begleitet, die dann meistens die Tests selbst als ungenügend kritisieren oder alles für alte Banane abtun, da Version X.Y.4a ihres Lieblingsprodukts ja alle genannten Kritikpunkte wegsprenge.

Richtig ist: Features und Konsistenz bedürfen nun mal Rechenzeit. Je nachdem, wie gut das DBMS programmiert ist, wählt es für jede der Aufgaben den minimalen Mechanismus im Sinne der zugrundeliegenden Architektur. Daraus ergeben sich für die ein oder andere Funktion verschiedene Laufzeiten. Im großen und ganzen sollte die Summe jedoch recht ausgeglichen sein.

Beide Datenbanken haben in den letzten Jahren durch den Hype von Open Source Software im Business-Umfeld offensichtlich stark zugelegt. Nicht zuletzt, weil die Anzahl der Installation und damit auch Anforderungen an diese und das Bug-Reporting ordentlich anstiegen. Dass die Daten gut verpackt und fehlerfrei so rauskommen, wie man diese einmal reingeworfen hat, das kann man beiden System also ohne Zweifel voraussetzen.

Wichtig im Sinne eines stressfreien Einsatzes erscheinen mir daher eher solche Dinge wie Installationshandling, Rechteverwaltung, Unterstützung häufiger Datenmanipulationsaufgaben oder In- bzw. Export von Daten.  Für Profis eventuell noch wichtig: Replikation, Failover oder Backup. Am meisten interessiert sicherlich das Gros der Leute, ob die PHP-Anbindung sauber funktioniert und alle Aufgaben einwandfrei unterstützt werden.

Wenn man mehrere parallele Threads laufen hat, zB bei gleichzeitigen Zugriffen auf eine gut besuchte Webseite mit vielen Datenbankoperationen, zählen sicherlich auch noch  andere Performance-Werte:

• Die Anzahl der konkurrierenden Zugriffe
• der dabei entstehende Speicherbedarf (“memory footprint”)
• das initiale Delay einer Abfrage.

Allerdings sind das Sphären, in denen die meisten DBA zu Replikation greifen werden. Wenn ein Server so am Anschlag ist, dann gibt man ihm doch am besten einen Partner zur Hand.

Deshalb habe ich beschlossen, es vorerst bei MySQL zu belassen. Ich werde also erst einmal schauen, was InnoDB mit Row Level Locking und Referenzieller Integrität für mich noch an Vorteilen zu bieten hat. Hier allein lassen sich schon Performance-Vergleiche anstellen und deren Ergebnisse im Alltag effektiv nutzen.

Erst dann kommt dann Postgres dran – zunächst wird es mir ums Handling gehen und später um die Performance – und zwar genau an den auch für InnoDB geeigneten Stellen. An dieser Stelle wird davon zu lesen sein.

Stay tuned !

Zuerst suchte ich eine schöne handliche Funktion, die mir eine Seitenstruktur aufwärts traversiert, um meine eigene, recht grobgeschnitzte Routine zur Anzeige der Navigation abzulösen.

Also erstmal nach CREATE FUNCTION gegoogelt, denn mein Buch PHP5/MySQL4 umschifft gekonnt dieses technische Terroir. Das Google-Ergebnis war frustrierend: Der wichtigste Link war schließlich die offizielle MySQL-Doku, in den Groups gab es ein paar Beiträge auf polnisch, was ich leider gar nicht verstehe.

Die auf der MySQL-Doku angegebene Syntax-Beschreibung waren abschreckend kompliziert dargestellt. Da muss jemand denken “Eine EBNF sagt mehr als 1000 Worte”. Da hat er wohl recht – wenn man einmal in der Materie drin ist. Wenn mans nicht ist, siehts ganz düster aus.

Eine andere Seite geht dafür den Top-down-Approach, auch mein Traversal-Problem ist hier als Beispiel-Lösung angegeben (juhu! dachte ich erst). Super einfühlsam, hier bleibt man jedoch nach den Überschriften etwas stecken. Denn das Beispiel funktionierte nicht.

Nach etwas Fiddelei stellte sich bei mir heraus: Zunächst war die Syntax “DELIMITER ;” nicht korrekt, dann muss man der Funktion immerhin noch sagen, ob diese READ SQL DATA oder anderen Typs ist. Nach der Syntax dann die Anweisung: Die Abbruchbedingung der WHILE-Schleife haute gar nicht hin. Angeblich soll ja diese Routine in MySQL-Syntax zu beherrschen sein, aber eine WHILE (NOT ISNULL(variable)) scheints nicht zu geben, hier rennt man in eine Endlosschleife. Mit Ctrl-C schießt man dabei leider nur seinen Client ab, der Server läuft mit dem Prozess dann in aller Ruhe weiter. Andere Bedingungen wie “(variable>)” stoppten bei NULL-Werten ebensowenig.

Nach ein paar Versuchen hatte der Server dann einen Load von 9.0 und MySQL eine Prozessorlast von konstant 200 Prozent erreicht. Mein vi hing, die Buchstaben waren eher per Fuß als per ssh auf dem Server. Mühsam schaffte ich es noch per top zu sehen, wer dran schuld war, so dass ich dann MySQL einfach stoppte und neu startete (die anderen in der Firma hatten hoffentlich gerade nix im Intranet zu tun:-)).

Also das war schon mal ein kleiner Reinfall. Meine Routine blieb.

Heute dann mehr Glück, wenn auch mit einem anderen Thema: Views und Indexes. Ich hatte zwischenzeitlich die Shop-Homepage mit einer Menge von Profiling-Anweisungen ausgestattet und konnte so die einzelnen Arbeitsschritte genau analysieren. Erstaunlich schnell konnte ich die “wunden Punkte” erkennen.

Mein erstes Fazit war: Lange Dateien per include in PHP-Code zu laden ist nicht schneller, als wenn es zwei kleinere Dateien sind. Meine Arbeitshypothese lautete bis dato noch: Weniger Dateien zu öffnen dauert nicht so lange wie ein sequentieller Lesevorgang einer Datei. Da lag ich wohl falsch, und bin nun froh, dass sinnvolles Strukturieren von include-Dateien “erlaubt” ist.

Zweites Fazit: Meine Arbeitshypothese, dass ich in Zukunft auf Apache’s mod_mem_cache setzen sollte, damit die ständig geladenen Seitenanteile nicht bei jedem Aufruf von der Platte gelesen werden müssen, ist hinfällig geworden: Nur 10% der gesamten Server-Bearbeitungszeit geht auf das Laden von Seiten zurück:

[PROFILING] => Array
(
[0] => Start
[1] => 0.0000: session.inc.php geladen (0.0000)
[2] => 0.0002: request.inc.php geladen (0.0002)
[3] => 0.0004: ssl.inc.php geladen (0.0002)
[4] => 0.0005: locale.inc.php geladen (0.0001)
[5] => 0.0009: sage.inc.php geladen (0.0004)
[6] => 0.0034: basic.inc.php geladen (0.0026)
[7] => 0.0036: waehrungen.inc.php geladen (0.0002)
[8] => 0.0040: db.inc.php geladen (0.0003)
[9] => 0.0043: db verbunden (0.0004)
[10] => 0.0043: Sortierung berechnet (0.0000)
[11] => 0.0066: konto.inc.php geladen (0.0023)
[12] => 0.0071: aktionen.inc.php geladen (0.0005)
[13] => 0.0074: menue_js.inc.php geladen (0.0003)
[14] => 0.0084: left.php geladen (0.0010)
[15] => 0.0084: goInsite(); (0.0000)
[16] => 0.0091: kategorie.inc.php geladen (0.0008)
[17] => 0.0096: Kopf ausgegeben (0.0005)
[18] => 0.4466: Artikel gefunden (0.4369)
[19] => 0.4471: Sortieren/Blaettern ausgegeben (0.0005)
[20] => 0.4521: Artikel ausgegeben (0.0050)
[21] => 0.4523: Blaettern ausgegeben (0.0001)
[22] => 0.4524: Entering _post.php (0.0001)
[23] => 0.4525: footer.inc.php geladen (0.0001)
[24] => 0.4584: right.inc.php geladen (0.0059)
[25] => 0.4600: menue.inc.php geladen (0.0016)
[26] => 0.4605: Seitenende (0.0005)
)

Hier sieht man schnell: von den 460 Millisekunden gehen 436 für die Artikelsuche in der Datenbank drauf.

Nach der Einführung von Indizes für einige Bereiche der Website und der Einführung eines Views für die Darstellung aller zur Zeit aktiven Artikel sieht das Ergebnis gleich ganz anders aus:

[PROFILING] => Array
(
[0] => Start
[1] => 0.0000: session.inc.php geladen (0.0000)
[2] => 0.0002: request.inc.php geladen (0.0002)
[3] => 0.0004: ssl.inc.php geladen (0.0002)
[4] => 0.0005: locale.inc.php geladen (0.0001)
[5] => 0.0009: sage.inc.php geladen (0.0004)
[6] => 0.0035: basic.inc.php geladen (0.0026)
[7] => 0.0037: waehrungen.inc.php geladen (0.0002)
[8] => 0.0040: db.inc.php geladen (0.0003)
[9] => 0.0044: db verbunden (0.0004)
[10] => 0.0044: Sortierung berechnet (0.0000)
[11] => 0.0067: konto.inc.php geladen (0.0023)
[12] => 0.0072: aktionen.inc.php geladen (0.0005)
[13] => 0.0074: menue_js.inc.php geladen (0.0003)
[14] => 0.0084: left.php geladen (0.0009)
[15] => 0.0088: goInsite(); (0.0004)
[16] => 0.0096: kategorie.inc.php geladen (0.0008)
[17] => 0.0102: Kopf ausgegeben (0.0006)
[18] => 0.0106: Artikel gefunden (0.0004)
[19] => 0.0111: Sortieren/Blaettern ausgegeben (0.0005)
[20] => 0.0142: Artikel ausgegeben (0.0031)
[21] => 0.0144: Blaettern ausgegeben (0.0001)
[22] => 0.0145: Entering _post.php (0.0001)
[23] => 0.0146: footer.inc.php geladen (0.0001)
[24] => 0.0205: right.inc.php geladen (0.0059)
[25] => 0.0236: menue.inc.php geladen (0.0031)
[26] => 0.0236: Seitenende (0.0000)
[max] => Array
(
[0] => 0.00587892532349
[1] => right.inc.php geladen
)
)

Und so wurden aus 461 ms 24 ms Gesamtladezeit.

Ich muss aber dazu sagen, dass die Einführung eines Views selbst zu keiner nennenswerten Performance-Steigerung führte. Die dabei gemessenen Ergebnisse sahen genauso, wenn nicht noch schlechter als die Abfrage der Originaltabelle aus. Erst die Indizes bringen die Performance, im obigen Beispiel ist dies immerhin eine Reduktion auf 5% der Original-Antwortzeit. Das eigentliche Problem, nämlich 1-2 Sekunden Rendering der Seite im IE7, ist damit (natürlich rein statistisch) auf 0.6-1.4 Sekunden geschrumpft. Dennoch werden wir hier nochmal ran, und diesmal den CSS-Code studieren müssen.

PS: Ich habe das View schließlich doch benutzt, damit mein Code einfacher und leichter wartbar wird. Eventuell werde ich den View noch auf die zur Artikelsuche relevanten Felder begrenzen, und die Messung damit wiederholen. Die großen Unterschiede wird es jedoch nicht mehr machen können. Und die Abweichungen jeder Messung sind augenscheinlich. Zweimal nacheinander eine ähnlich Abfrage bringt allein durch das Caching der Datenbank alle Ergebnisse durcheinander.