nicht angemeldet
Hi auch,
Alle 10 minuten wird die Datenbank durchforstet und alle Artikel
werden ausgespuckt. Diese werden dann nach Kategorie und Sub-
Kategorie in eigene php-Dateien geschrieben die halt irgendwo
liegen.
Ah! Du willst also einen serverseitigen Cache vor Deine Datenbank
legen - richtig?
Wenn ein User jetzt durch die Artikel durchsucht , schickt er also
nicht jedes Mal eine Abfrage an die Datenbank, die dann den Eintrag
raussucht, sondern sucht sich die daten heraus, die in dem php-file
stehen.
Wird diese PHP-Datei einfach nur ausgeliefert, oder wird aus ihr
wirklich noch etwas "herausgesucht"? Denn letzteres wäre per Daten-
bankzugriff wahrscheinlich sogar schneller möglich.
Hoffentlich kann damit jemand mehr anfangen!
Ein Cache macht dann Sinn, wenn Du
- glaubst, sehr viele Lesezugriffe auf einen sich nur selten ändernden,
aber aufwändig zu berechnenden Inhalt zu bekommen und - damit leben kannst, daß dieser Inhalt nicht absolut echtzeit-korrekt
ist.
Beschreibt dies Dein Szenario angemessen?
Meines Wissens macht das ebay genaus so. Erst wenn man dann auf
einen Artikel klickt, und die Details sieht wird die Datenbank in
Anspruch genommen.
Die Fragen, die Du Dir stellen solltest, lauten also vermutlich:
a) Habe ich wirklich so irre viele Zugriffe wie Ebay?
b) Kostet mich die Berechnung der Seite wirklich so irre viel, daß die
Implementierung eines solchen Cache-Mechanismus gerechtfertigt ist?
c) Falls b) zutrifft, kann ich an der Infrastruktur meines Datenzugriffs
etwas ändern (beispielsweise an den Indexdefinitionen der Tabellen),
um das Problem mit geringerem Aufwand in den Griff zu bekommen?
Viele Grüße
Michael
(der in einem einzigen Fall schon mal einen solchen Cache realisiert hat,
weil die Berechnungsdauer im einstelligen Sekundenbereich pro Seite lag,
die Berechnung von einem black box binary realisiert wurde und die Anzahl
der Zugriffe schwer vorhersehbar war, wie aber einen provozierbaren Last-
Peak vermeiden wollten)