- Ad -
php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Scripts > BRAINSTORMING PHP/SQL/HTML/JS/CSS
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 

 


BRAINSTORMING PHP/SQL/HTML/JS/CSS Ihr habt eine Idee, aber keinen genauen Ansatz? Diskutiert mit anderen Usern des Forums über eure Gedankengänge um evtl. hilfreiche Ideen zu bekommen!
Normale Fragen bitte weiterhin in die entsprechenden Foren!

Antwort
 
LinkBack Themen-Optionen Bewertung: Bewertung: 1 Stimmen, 5,00 durchschnittlich.
  #1 (permalink)  
Alt 07-09-2007, 10:34
Lennynero
 Registrierter Benutzer
Links : Onlinestatus : Lennynero ist offline
Registriert seit: Sep 2007
Beiträge: 121
Blog-Einträge: 1
Lennynero ist zur Zeit noch ein unbeschriebenes Blatt
Standard 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
Mit Zitat antworten
  #2 (permalink)  
Alt 07-09-2007, 10:57
ghostgambler
 Master
Links : Onlinestatus : ghostgambler ist offline
Registriert seit: Jul 2004
Ort: DE - NRW
Beiträge: 4.620
ghostgambler ist zur Zeit noch ein unbeschriebenes Blatt
Standard Re: Cachen von MySQL-Abfrage, Ergebnissen, HTML-Seiten und -teilen mit PHP und MySQL

Zitat:
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...

Zitat:
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...

Zitat:
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"


Zitat:
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~

Zitat:
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

Zitat:
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
Mit Zitat antworten
  #3 (permalink)  
Alt 07-09-2007, 11:57
Lennynero
 Registrierter Benutzer
Links : Onlinestatus : Lennynero ist offline
Registriert seit: Sep 2007
Beiträge: 121
Blog-Einträge: 1
Lennynero ist zur Zeit noch ein unbeschriebenes Blatt
Standard Re: Re: Cachen von MySQL-Abfrage, Ergebnissen, HTML-Seiten und -teilen mit PHP und My

Vorneweg erstmal ein Riesendankeschoen fuer die Antwort.

Zitat:
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


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


Zitat:
... 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.

Zitat:
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.

Zitat:
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.

Zitat:
Hundert MB ist zuviel xP
Gut zu wissen

Zitat:
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.
Mit Zitat antworten
  #4 (permalink)  
Alt 07-09-2007, 12:24
ghostgambler
 Master
Links : Onlinestatus : ghostgambler ist offline
Registriert seit: Jul 2004
Ort: DE - NRW
Beiträge: 4.620
ghostgambler ist zur Zeit noch ein unbeschriebenes Blatt
Standard Re: Re: Re: Cachen von MySQL-Abfrage, Ergebnissen, HTML-Seiten und -teilen mit PHP un

Zitat:
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~


Zitat:
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~)

Zitat:
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


Zitat:
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...
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

Zeit ist Geld, PC einfach selbst reparieren!
Zeit ist Geld, PC einfach selbst reparieren!Wenn der PC nicht richtig läuft, wirft sie das in Ihrem Arbeitsalltag meist zurück. Dabei können Sie einige Probleme mit relativ wenig Aufwand und ohne intime Kenntnisse Ihres Rechners selbst lösene

18.04.2016 | Berni

Die wichtigsten Rahmenbedingungen für das Hosting
Die wichtigsten Rahmenbedingungen für das HostingGuter Webspace wird in der heutigen Zeit immer wichtiger. Die Scripte werden moderner und fordern höhere Leistung, der allgemeine Traffic im Internet nimmt zu.

17.08.2015 | Berni


 

Aktuelle PHP Scripte

Onlineshop mit CSV Artikel import

Wir erstellen nach Ihren Wünschen Ihren Onlineshop.

11.07.2016 ISD-Genthin | Kategorie: PHP/ Shops
Newsletter PRO SQL V4

Nutzen Sie unser Newsletter-System und halten Sie Ihre Kunden mit neuen Informationen stets auf dem Laufenden. Die benutzerfreundliche Oberfläche bietet sowohl Anfängern als auch Profis, die Erstellung von eleganten bis frechen Newslettern ...

11.07.2016 virtualsystem | Kategorie: PHP/ News
LEPTON CMS ansehen LEPTON CMS

LEPTON CMS ist eine weiterentwickelte Ableitung (Fork) des CMS „WebsiteBaker“ der Version 2.8.1. Das Entwicklerteam hat den ursprünglichen „Geist” erhalten, der dieses Content Management System und seine damalige Community unter Leitung des Gründers Ryan

27.06.2016 erpe | Kategorie: PHP/ CMS
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 22:04 Uhr.