Cachen von MySQL-Abfrage, Ergebnissen, HTML-Seiten und -teilen mit PHP und MySQL

**ghostgambler** · 07.09.2007, 10:57

Re: Cachen von MySQL-Abfrage, Ergebnissen, HTML-Seiten und -teilen mit PHP und MySQL

Original geschrieben von Lennynero
Generell moechte ich den MySQL-Query-Cache aktivieren, dort bin ich mir aber nicht sicher welche Cachegroesse sinnvoll ist. Die Suche in Newsgroups und im Web hat mich da auch nicht wirklich weiter gebracht, hat da jemand Erfahrungen, bzw. kennt entsprechende Quellen?

Wir haben bei 16 Gig Ram, 200 MB, bei einer eher write-lastigen Anwendung.
Zu deutlich mehr würde ich auch nicht raten - der QC versackt dann irgendwann~ bei uns äußerte sich das dahingehend, dass ich irgendwann angerufen wurde und mir mitgeteilt wurde, dass der Seitenaufbau statt 0.5 Sekunden 5 Sekunden braucht, Reduktion auf 200 MB ließ dann alles wieder flott laufen...
Kann bei uns ein Einzelfall gewesen sein, aber ich habe auch von anderen Fällen gelesen, wo ein zu großer QC zu Problemen geführt hat ... scheinbar ist (oder zumindest war) MySQL da nicht so ausgereift...

Als naechstes moechte ich Ergebnisse und Daten ebenfalls cachen (unter Ergebnisse verstehe ich Daten aus verschiedenen Abfragen, die innerhalb eines Skriptes abgefragt werden, bei denen die entsprechende SQL-Abfrage nicht moeglich ist, oder einfach zu lange dauert).
Und weil das ja noch nicht reicht... gibt es Daten

a - Die man fuer alle User cachen koennte
b - Die speziell einem User zugeordnet sind

Derzeit habe ich z.B. die Stammdaten der Kunden in einem Array in der SESSION abgelegt. Da ein Kunde von mehreren Usern aufgerufen werden kann, waere es evt. sinnvoll diese Abfrageergebnisse in anderer Form (z.B. ein Verzeichnis mit XML-Dateien) abzulegen (und dann "einfach" ueber die kunden_id abzufragen). Der Nachteil dabei waere allerdings, das sich die Kundenzahl ja stetig erhoeht (derzeit ca 13000, und es werden nicht weniger, wobei wohl einige Altkunden nicht mehr so haeufig aufgerufen werden). Waere es da ein Problem alte Dateien nicht zu loeschen, oder sollte man regelmaessig das Verzeichnis durchforsten und dann bei Bedarf die Dateien wieder neu generieren?

Du redest von Cache und XML in einem Satz? Lustig ^^
Cachen in der Datenbank reicht für gewöhnlich aus - und wenn nicht, dann kommt XML auch nicht mehr in Frage...

Seitenelemente, und ganze HTML-Seiten.... auch hier haben wir wieder Seitenelemente, die fuer alle User gleich sind (Tabellen, generelle Menus), und Elemente, die Userspezifisch sind (wiederrum Menus). Ganze Seiten waeren dann fuer alle gleich.

... und?
Statische Inhalte sind statisch, daran rumzuoptimieren, hat soviel Sinn wie beim Saugen nochmal mit einem Staubtuch nachwischen - ein bisschen was ja, aber nix großartiges...

Was man z.B. cachen kann sind Statistiken über die Mitglieder... wenn man z.B. darstellen will wie viele Mitglieder die Website hat und wie viele davon männlich/weiblich sind, dann kann man ein

PHP-Code:


if (file_exists($cachefile)) {

  require($cachefile);

} else {

  ob_start();

  echo "meine Statistik";

  $die_statistik = ob_get_clean();

  ob_end();

  $fp = fopen($cachefile, "w+");

  fput($fp, $die_statistik);

  fclose($fp);

  echo $die_statistik;

}

machen - das hat viel Sinn, wenn die Berechnung aufwändig und die Statistik häufig aufgerufen wird... wenn die Statistik aber wiederum nur aus
SELECT anz_mitglieder, prozent_männlich, prozent_weiblich FROM counter_tabelle
besteht und 3 Mal pro Tag aufgerufen wird, dann hat das wieder keinen Sinn, sowas optimieren zu wollen... da ist die Arbeitszeit zu teuer xD"

Bisher habe ich einige Daten in den Sessions der User abgelegt, bin mir aber nicht sicher, ob die Groesse der Session dann nicht ein Problem werden koennte (derzeit greifen etwa 60 aktive User auf die Daten zu, auch hier ist zu erwarten das es mehr werden).

Solange du keine Größenwerte in den Raum wirfst kann man nur spekulieren~

Auch zu der Frage wie gross eine Session sein darf, bin ich bisher nicht fuendig geworden, vielleicht hat da jemand Input fuer mich

Hundert MB ist zuviel xP

Auch bei dem Problem Cache (als XML), oder neue MySQL-Abfragen bin ich mir nicht sicher, ob eine einfache SQL-Abfrage nicht vielleicht doch systemschonender ist, als der XML-Dateiaufruf.

eben~

Guck halt, wo die Anwendung wirklich langsam ist und optimiere das.
Als hilfreich haben sich auch schon MEMORY/HEAP-Tabellen erwiesen... da liegen bei uns z.B. schon 2 Tabellen komplett drin, einmal User-Daten

OffTopic:
das erlaubt uns z.B. solche Dinge

PHP-Code:

$result = mysql_query("SELECT * FROM daten"); while ($row = mysql_fetch_assoc($result)) { $user_daten = mysql_fetch_assoc(mysql_query("SELECT * FROM userdaten WHERE user_id = " . $row['user_id'])); var_dump($row, $user_daten); }

was auf den ersten Blick für jeden DB-Server tödlich ist, erlaubt uns auf JOINs fast gänzlich zu verzichten (und zudem die Ausgabe des Usernames in einer Funktion zu kapseln, was dann und wann doch schon angenehm ist beim Programmieren

und einmal ein kopierter Datenbestand eines hoch-frequentierten Projektes.

OffTopic:
da liegen die richtigen Daten in einer myisam-Tabelle, und alles in Kopie + Cache-Spalten in einer HEAP-Tabelle, was den Ablauf beschleunigt

Das kann man wiederum aber auch nicht uneingeschränkt empfehlen! MyISAM verwendet für Indizes einen B-Baum-Index - MEMORY kann technisch bedingt nur Hash-Indizes und diese können bei weitem langsamer sein ... war zum Beispiel beim Forum der Fall, da wurde die Heap-Tabelle recht schnell wieder abgesägt~

Eine weitere Optimierungsmöglichkeit sind Semaphoren.
Beliebt zum Beispiel für Counter-Stat-Tabellen, welche die Lese-Last der Tabelle in eine Schreib-Last umkehren (können).

Ich denke du solltest die Anwendung erstmal ans Laufen bringen, dann schauen was wirklich langsam ist, und dann mit einem konkreten Problem wieder kommen~
Ansonsten kann man halt nur generelles Blabla absondern

**Lennynero** · 07.09.2007, 11:57

Re: Re: Cachen von MySQL-Abfrage, Ergebnissen, HTML-Seiten und -teilen mit PHP und My

Vorneweg erstmal ein Riesendankeschoen fuer die Antwort.

Original geschrieben von ghostgambler Wir haben bei 16 Gig Ram, 200 MB, bei einer eher write-lastigen Anwendung.
Zu deutlich mehr würde ich auch nicht raten - der QC versackt dann irgendwann~ bei uns äußerte sich das dahingehend, dass ich irgendwann angerufen wurde und mir mitgeteilt wurde, dass der Seitenaufbau statt 0.5 Sekunden 5 Sekunden braucht, Reduktion auf 200 MB ließ dann alles wieder flott laufen...

Also wie ueblich, letzten Endes testen... wobei ich eine wesentlich kleinere Groesse erwartet haette

Du redest von Cache und XML in einem Satz? Lustig ^^
Cachen in der Datenbank reicht für gewöhnlich aus - und wenn nicht, dann kommt XML auch nicht mehr in Frage...

Cachen als temporaere Tabelle (wobei die dann ja immer nur einem User zugaenglich waeren)? Oder wuerden sich fuer komplexe Queries Views besser eignen?

(ich denke mittlerweile sollte klar sein, das ich mich bisher nicht allzuviel mit cachen beschaeftigt habe).

... und?
Statische Inhalte sind statisch, daran rumzuoptimieren, hat soviel Sinn wie beim Saugen nochmal mit einem Staubtuch nachwischen - ein bisschen was ja, aber nix großartiges...

Mit "ganze Seiten" meinte ich keine statischen Seiten, die Inhalte werden schon dynamisch generiert, sind aber fuer alle User gleich.

Was man z.B. cachen kann sind Statistiken über die Mitglieder... wenn man z.B. darstellen will wie viele Mitglieder die Website hat und wie viele davon männlich/weiblich sind, dann kann man ein

PHP-Code:


if (file_exists($cachefile)) {

  require($cachefile);

} else {

  ob_start();

  echo "meine Statistik";

  $die_statistik = ob_get_clean();

  ob_end();

  $fp = fopen($cachefile, "w+");

  fput($fp, $die_statistik);

  fclose($fp);

  echo $die_statistik;

}

machen - das hat viel Sinn, wenn die Berechnung aufwändig und die Statistik häufig aufgerufen wird... wenn die Statistik aber wiederum nur aus
SELECT anz_mitglieder, prozent_männlich, prozent_weiblich FROM counter_tabelle
besteht und 3 Mal pro Tag aufgerufen wird, dann hat das wieder keinen Sinn, sowas optimieren zu wollen... da ist die Arbeitszeit zu teuer xD"

Das meiste ist dann doch etwas komplexer.... wir haben z.B. eine Kundensicht, und um die zu generieren werden Daten aus 12 Tabellen angefragt. Dieser Informationsblock wurde urspruenglich bei jedem Seitenaufruf neu abgefragt, mittlerweile habe ich den in die Session der User geschrieben, wobei mich hier mittlerweile aergert, das ja auch mehrere User auf einen Kunden zugreifen koennen und im Grunde unnoetigerweise mehrmals die gleichen Daten in den Sessions stehen.

Solange du keine Größenwerte in den Raum wirfst kann man nur spekulieren~

Naja, gehen wir mal von derzeit 70 Benutzern aus, bei den meisten wird die Sessiondatei nicht groesser als 200kB, jedoch koennen auchmal Groessenordnungen wie z.B. 2 bis 3 MB vorkommen.

Hundert MB ist zuviel xP

Gut zu wissen

Ich denke du solltest die Anwendung erstmal ans Laufen bringen, dann schauen was wirklich langsam ist, und dann mit einem konkreten Problem wieder kommen~
Ansonsten kann man halt nur generelles Blabla absondern

Nochmal danke fuer deine schnelle Antwort... und im Grunde ging es mir auch erstmal um generelles (oder gar grundlegenedes) Blabla, denn bisher haben wir uns nicht wirklich viel Gedanken um die Performance gemacht, sondern immer nur dann, wenn Probleme aufgetreten sind. Es ist mir auch klar, das man im Vorfeld sicherlich nicht alle kommenden Probleme vermeiden kann, trotzdem ist es sicherlich nicht verkehrt beim Entwurf schon den einen oder anderen SChritt mit zu bedenken.

**ghostgambler** · 07.09.2007, 12:24

Re: Re: Re: Cachen von MySQL-Abfrage, Ergebnissen, HTML-Seiten und -teilen mit PHP un

Original geschrieben von Lennynero
Also wie ueblich, letzten Endes testen... wobei ich eine wesentlich kleinere Groesse erwartet haette

Es kommt halt drauf an ... es gibt Anwendungen, da hat der QC überhaupt keinen Sinn und es gibt Anwendungen da ist der QC der Booster schlechthin~

Cachen als temporaere Tabelle (wobei die dann ja immer nur einem User zugaenglich waeren)? Oder wuerden sich fuer komplexe Queries Views besser eignen?

Temporäre Tabelle muss ja nicht temporäre Tabelle im Sinne von mysql heißen ... nur weil eine Tabelle eine normale myisam-Tabelle ist, kann sie ja trotzdem nur temporär sein (darf dann natürlich nicht mit CREATE TEMPORARY TABLE erstellt werden~)

Das meiste ist dann doch etwas komplexer.... wir haben z.B. eine Kundensicht, und um die zu generieren werden Daten aus 12 Tabellen angefragt. Dieser Informationsblock wurde urspruenglich bei jedem Seitenaufruf neu abgefragt, mittlerweile habe ich den in die Session der User geschrieben, wobei mich hier mittlerweile aergert, das ja auch mehrere User auf einen Kunden zugreifen koennen und im Grunde unnoetigerweise mehrmals die gleichen Daten in den Sessions stehen.

Ja, das mit der Session klingt in dem Fall idT einfach nur schlecht...
Je nachdem was zum Beispiel aus den 12 Tabellen abgefragt wird, wäre das ein Anwendungsfall für eine temporäre Tabelle (ob myisam oder heap ist ja egal) - die kann man dann einfach um Spalten erweitern und muss dann aus den 12 Tabellen nur einmal abfragen

Naja, gehen wir mal von derzeit 70 Benutzern aus, bei den meisten wird die Sessiondatei nicht groesser als 200kB, jedoch koennen auchmal Groessenordnungen wie z.B. 2 bis 3 MB vorkommen.

Ich persönlich find das schon recht viel.
Wenn man bedenkt, dass in 2 MB schon ein kompletter Blog passt...

Cachen von MySQL-Abfrage, Ergebnissen, HTML-Seiten und -teilen mit PHP und MySQL