Gebruik de ingebouwde querycache van MySQL in plaats van deze zelf te onderhouden. Query's in de cache worden automatisch gewist wanneer er naar tabellen wordt geschreven. Bovendien werkt het in het geheugen, dus het zou zeer efficiënt moeten zijn...
Cache-query's niet alleen in de cache. Probeer volledige segmenten van de toepassing in verschillende stadia van de weergavecyclus te cachen. U kunt MySQL de query's dus in de cache laten plaatsen, waarna u elke afzonderlijke weergave (gerenderd), elk afzonderlijk blok en elke pagina in de cache opslaat. Vervolgens kunt u op basis van het verzoek kiezen of u al dan niet uit de cache wilt ophalen.
Een niet-ingelogde gebruiker kan bijvoorbeeld de volledige pagina rechtstreeks uit de cache halen. Maar een ingelogde gebruiker kan dit mogelijk niet (vanwege gebruikersnaam, enz.). Dus voor hem kun je misschien de helft van je weergaven op de pagina weergeven vanuit de cache (omdat ze niet afhankelijk zijn van het gebruikersobject). U profiteert nog steeds van het voordeel van caching, maar het wordt gedifferentieerd op basis van behoefte.
Als je echt veel verkeer verwacht, is het zeker de moeite waard om te kijken naar Memcached
. Laat MySQL uw zoekopdrachten voor u opslaan en sla vervolgens alle cache-items van gebruikers op in memcache...
Bewerken: Om je bewerking te beantwoorden:
Bestandssystemen kunnen traag worden als een enkele map groot wordt. Zolang je "namespacing" per map gebruikt (dus elke map heeft slechts een klein deel van de cachebestanden), zou het vanuit dat oogpunt goed moeten komen. Wat betreft de exacte drempel, het zal meer dan wat dan ook afhangen van je hardware en bestandssysteem. Ik weet dat EXT3 behoorlijk traag wordt als er veel bestanden in een enkele map staan (ik heb mappen met letterlijk honderdduizenden bestanden, en het kan tot een halve seconde duren om simpelweg stat() een van de bestanden, laat staan een directorylijst maken)...
Maar realiseer je dat als je een andere server toevoegt, je ofwel een dubbele cache krijgt (wat niet goed is), ofwel je hele cachelaag moet herschrijven. Is er een reden om niet met Memcached te gaan? vanaf het begin?
BEWERK 2: Om je laatste bewerking te beantwoorden:
Bellen is nog te moeilijk. Ik heb een applicatie met een database met ongeveer 1,5 miljard rijen (groeiend met ongeveer 500k per dag). We gebruiken er helemaal geen caching op omdat we geen concurrency-problemen hebben. En zelfs als we dat zouden doen, zouden we er beter aan doen om er meer MySQL-servers op te gooien in plaats van caching toe te voegen, aangezien elke vorm van cache zo'n lage hitrate zou hebben dat het de ontwikkelingstijd niet waard zou zijn om het toe te voegen.
En dat is de reden waarom ik zo onvermurwbaar ben om niet te cachen voor snelheid. Er zal altijd een object zijn dat zich niet in de cache bevindt. Dus als je een pagina raakt met een van die objecten, moet het nog steeds snel zijn. Als vuistregel probeer ik alles in de cache te plaatsen dat in de komende minuten opnieuw zal worden geopend (ik houd sowieso een time-to-live van ongeveer 5 minuten in productie op andere applicaties). Dus als items in die periode niet meer dan een paar hits krijgen, of als het hitpercentage erg laag is (minder dan 90%), neem ik niet de moeite om dat item in de cache te plaatsen....