Verwenden Sie den integrierten Abfrage-Cache von MySQL, anstatt zu versuchen, ihn selbst zu warten. Es löscht automatisch zwischengespeicherte Abfragen für Tabellen, wenn in sie geschrieben wird. Außerdem arbeitet es im Speicher, also sollte es sehr effizient sein...
Cachen Sie Abfragen auch nicht einfach. Versuchen Sie, ganze Segmente der Anwendung in verschiedenen Phasen des Renderingzyklus zwischenzuspeichern. So können Sie MySQL die Abfragen cachen lassen, dann cachen Sie jede einzelne Ansicht (gerendert), jeden einzelnen Block und jede Seite. Dann können Sie basierend auf der Anfrage wählen, ob Sie aus dem Cache abrufen möchten oder nicht.
Beispielsweise kann ein nicht angemeldeter Benutzer die vollständige Seite direkt aus dem Cache abrufen. Ein angemeldeter Benutzer kann dies jedoch möglicherweise nicht (aufgrund des Benutzernamens usw.). Für ihn können Sie also möglicherweise die Hälfte Ihrer Ansichten auf der Seite aus dem Cache rendern (da sie nicht vom Benutzerobjekt abhängen). Sie profitieren immer noch vom Caching, aber es wird je nach Bedarf abgestuft.
Wenn Sie wirklich viel Verkehr erwarten, lohnt es sich auf jeden Fall, sich mit Memcached zu befassen
. Lassen Sie MySQL Ihre Abfragen für Sie speichern und speichern Sie dann alle User-Land-Cache-Elemente in Memcache ...
Bearbeiten: So beantworten Sie Ihre Änderung:
Dateisysteme können langsam werden, wenn ein einzelnes Verzeichnis groß wird. Solange Sie nach Verzeichnissen "namespacen" (also jedes Verzeichnis nur einen kleinen Teil der Cache-Dateien enthält), sollten Sie von diesem Standpunkt aus in Ordnung sein. Der genaue Schwellenwert hängt mehr als alles andere von Ihrer Hardware und Ihrem Dateisystem ab. Ich weiß, dass EXT3 ziemlich langsam wird, wenn es eine Menge Dateien in einem einzelnen Verzeichnis gibt (ich habe Verzeichnisse mit buchstäblich Hunderttausenden von Dateien, und es kann bis zu einer halben Sekunde dauern, bis einfach stat() eine der Dateien, ganz zu schweigen von irgendeiner Verzeichnisliste)...
Beachten Sie jedoch, dass Sie beim Hinzufügen eines weiteren Servers entweder den Cache duplizieren (was nicht gut ist) oder Ihre gesamte Cache-Schicht neu schreiben müssen. Gibt es einen Grund, sich nicht für Memcached zu entscheiden? von Anfang an?
BEARBEITEN 2: So beantworten Sie Ihre letzte Änderung:
Es ist immer noch zu schwierig anzurufen. Ich habe eine Anwendung mit einer Datenbank mit etwa 1,5 Milliarden Zeilen (die um etwa 500.000 pro Tag wächst). Wir verwenden überhaupt kein Caching, da wir keine Parallelitätsprobleme haben. Und selbst wenn wir das täten, wären wir besser dran, mehr MySQL-Server darauf zu werfen, als Caching hinzuzufügen, da jede Form von Cache eine so niedrige Trefferquote hätte, dass es die Entwicklungszeit nicht wert wäre, sie hinzuzufügen.
Und das ist der Grund, warum ich so hartnäckig bin, nicht aus Geschwindigkeitsgründen zwischenzuspeichern. Es wird immer ein Objekt geben, das sich nicht im Cache befindet. Wenn Sie also eine Seite mit einem dieser Objekte treffen, muss es trotzdem schnell sein. Als Faustregel versuche ich, alles zwischenzuspeichern, auf das in den nächsten Minuten wieder zugegriffen wird (ich halte sowieso eine Lebensdauer von etwa 5 Minuten in der Produktion bei anderen Anwendungen ein). Wenn also Artikel in dieser Zeitspanne nicht mehr als ein paar Treffer erhalten oder die Trefferquote sehr niedrig ist (weniger als 90 %), mache ich mir nicht die Mühe, diesen Artikel zwischenzuspeichern ....
