Użyj wbudowanej pamięci podręcznej zapytań MySQL, zamiast próbować samodzielnie ją obsługiwać. Automatycznie wyczyści buforowane zapytania do tabel podczas ich zapisywania. Dodatkowo działa w pamięci, więc powinien być bardzo wydajny...
Ponadto nie przechowuj tylko zapytań w pamięci podręcznej. Spróbuj buforować całe segmenty aplikacji na różnych etapach cyklu renderowania. Możesz więc pozwolić MySQL na buforowanie zapytań, a następnie buforujesz każdy pojedynczy widok (renderowany), każdy pojedynczy blok i każdą stronę. Następnie możesz wybrać, czy chcesz pobrać z pamięci podręcznej, na podstawie żądania.
Na przykład niezalogowany użytkownik może pobrać całą stronę bezpośrednio z pamięci podręcznej. Ale zalogowany użytkownik może nie być w stanie (z powodu nazwy użytkownika itp.). Więc dla niego możesz być w stanie wyrenderować 1/2 swoich widoków na stronie z pamięci podręcznej (ponieważ nie zależą one od obiektu użytkownika). Nadal czerpiesz korzyści z buforowania, ale będzie ono podzielone na warstwy w zależności od potrzeb.
Jeśli naprawdę spodziewasz się dużego ruchu, zdecydowanie warto zajrzeć do Memcached
. Niech MySQL przechowuje Twoje zapytania za Ciebie, a następnie przechowuje wszystkie elementy pamięci podręcznej w przestrzeni użytkownika w pamięci podręcznej...
Edytuj: Aby odpowiedzieć na edycję:
Systemy plików mogą stać się wolniejsze, jeśli pojedynczy katalog rozrasta się. Tak długo, jak "przestrzenie nazw" według katalogu (więc każdy katalog ma tylko niewielką część plików pamięci podręcznej), z tego punktu widzenia powinno być dobrze. Jeśli chodzi o dokładny próg, to naprawdę będzie zależeć od twojego sprzętu i systemu plików bardziej niż cokolwiek innego. Wiem, że EXT3 działa dość wolno, jeśli w jednym katalogu jest dużo plików (mam katalogi z dosłownie setkami tysięcy plików, a samo stat() może zająć nawet pół sekundy jeden z plików, nie mówiąc już o jakiejkolwiek liście katalogów)...
Ale zdaj sobie sprawę, że jeśli dodasz kolejny serwer, albo będziesz miał duplikację pamięci podręcznej (co nie jest dobrą rzeczą), albo będziesz musiał przepisać całą warstwę pamięci podręcznej. Czy istnieje powód, aby nie korzystać z Memcached? od samego początku?
EDYCJA 2: Aby odpowiedzieć na ostatnią zmianę:
Nadal jest zbyt trudno zadzwonić. Mam aplikację, która ma bazę danych zawierającą około 1,5 miliarda wierszy (rosnąca w tempie około 500 tys. dziennie). W ogóle nie używamy na nim buforowania, ponieważ nie mamy problemów ze współbieżnością. A nawet gdybyśmy to zrobili, lepiej byłoby wrzucić do niego więcej serwerów MySQL niż dodawać buforowanie, ponieważ każda forma bufora miałaby tak niski współczynnik trafień, że dodanie go nie byłoby opłacalne.
I to jest powód, dla którego jestem tak nieugięty, aby nie buforować szybkości. Zawsze znajdzie się obiekt, którego nie ma w pamięci podręcznej. Więc jeśli trafisz na stronę z jednym z tych obiektów, nadal musi być szybki. Z reguły staram się buforować wszystko, do czego będzie można uzyskać dostęp w ciągu najbliższych kilku minut (i tak utrzymuję czas życia około 5 minut w produkcji na innych aplikacjach). Więc jeśli przedmioty nie uzyskują więcej niż kilka trafień w tym okresie lub współczynnik trafień jest bardzo niski (mniej niż 90%), nie zawracam sobie głowy buforowaniem tego elementu....
