nicht angemeldet
Moin!
So, und angesichts dieser Tatsachen, erscheint es mir sehr abwegig,
diese Klasse nicht sitzungs-persistent zu cachen, da auf diese Art
und Weise gut >paar Dutzend DB-Anfragen entfallen würden.
"Don't optimize it if you can't measure it."
Du mußt ja immer auch die potentielle Gleichzeitigkeit von Zugriffen innerhalb derselben Session beachten. Ein Cache ist zwar schön und gut, aber indem du die Cache-Logik in PHP realisierst, hast du nicht mehr nur exakt EINEN Cache, sondern dir entsteht mit jedem PHP-Prozess einer. Daran ändern auch Sessions nichts. Zumal Sessions ja auch irgendwie gespeichert werden müssen. Und genau dort sähe ich ein potentielles Problem, denn wenn du so viele Sessions gleichzeitig hast, dass die Datenbank in Schwierigkeiten kommt mit den Abfragen, dann hast du mit Sicherheit auch Probleme mit der HD-Performance bei der Session-Speicherung - denn bekanntlich ist es im Filesystem nicht gut für die Zugriffszeiten, wenn ein Verzeichnis sehr viele Dateien enthält.
Abgesehen davon müssen natürlich die Schreibzugriffe auf die Sessiondaten serialisiert werden. Es ist daher eine gute Idee, die Menge zu schreibender Daten klein zu halten. Das gilt im gleichen Maße auch für eigenentwickelte Mechanismen, die in Dateien speichern.
Im übrigen haben gute Datenbanken alle ihren eigenen Cache schon eingebaut, so dass identische Abfragen sehr schnell bedient werden können. Und genau an diesem Ort macht so ein Cache auch Sinn. Sollte deine Datenbank keine Möglichkeit dazu bieten, würde sich vielmehr anbieten, dass du dir dann lieber eine cachende DB-API schreibst, die gegenüber der PHP-Applikation wie die Datenbank arbeitet, und seinerseits die Requests zur DB durchreicht. Sowas ist aber definitiv etwas komplizierter und erfordert logischerweise auch die Möglichkeit, es auf dem Server installieren zu können - das ist also nichts für simplen "Webspace".
- Sven Rautenberg
My sssignature, my preciousssss!