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

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

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

    Hallo,

    wir sind drauf und dran unser selbst programmiertes CRM neu aufzusetzen, und haben jetzt natuerlich Gelegenheit einige Altlasten ueber Board zu werfen.

    Nun bin ich am ueberlegen, an welcher Stelle das cachen von Abfragen, deren Ergebnissen, Daten, Seitenelementen und kompletten Seiten sinnvoll ist... aber von vorne:
    1. 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?
    2. 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?
    3. 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.


    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).

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

    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.

    So, ich hoffe man kann da meine Probleme verstehen... und bin mal auf Antworten gespannt.


    Gruss,
    Markus

  • #2
    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

    Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

    bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
    Wie man Fragen richtig stellt

    Kommentar


    • #3
      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.

      Kommentar


      • #4
        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...

        Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

        bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
        Wie man Fragen richtig stellt

        Kommentar

        Lädt...
        X