Cache strony - kilka pytań, Prośba o rady i sugestie Opcje

[Pilsener]

Witajcie

Mam do stworzenia system, w którym duży nacisk kładzie się na liczbę zapytań do bazy, mam już w głowie koncepcję cache, ale nie wiem czy słuszną:

I. Menu + drzewo kategorii - tu sprawa wydaje się prosta: menu stworzone w PA jest zapisane w pliku, który includujemy i pewnie co jakiś czas odświeżamy, ale tu pierwsze pytania:
1. Czy używać zwykłego pliku .php czy iść w stronę trzymania cache'u w xml?
2. Czy cache poddawać jakiejś kompresji? Nie wydaje mi się to rozsądne.
3. Co z sytuacją, kiedy menu wygląda inaczej na różnych podstronach? (typowe menu z pozagnieżdżanymi podkategoriami) - cache dla każdej kategorii inne czy raczej wspólne dla wszystkich + niewielka obróbka w php (ale wzrasta zużycie zasobów, bo wczytywane są wszystkie podkategorie no i plus obróbka tego)
4. Jak odświeżać cache? Co jakiś czas skryptowo, cronem czy odpalać klasę/funkcję w określonych sytuacjach (np. edycja meta-danych jakiejś kategorii)? A może łączyć te metody, pozwolić wybrać userowi w PA?

II. Moduły z dynamiczną treścią - np. system artykułów czy forum - jakoś nie widzę cache'owania tego, zbyt duża zmienność, zbyt duża liczba akcji i opcji - planuję zostawić jak jest.

III. Wczytywanie meta-danych - byłoby prosto, gdyby były statyczne dla każdej kategorii lub całej strony - ale są generowane nierzadko na podstawie treści, która też jest generowana dynamicznie (np. z systemu newsów), wsparcie dla SEO przewiduje też różne "mieszane" tryby generowania meta, w oparciu o wartościowanie słów kluczowych, na które pozycjonujemy stronę... okropieństwo
5. Czy w związku z tym zrobić cache meta-danych dla drzewa kategorii i tylko aktualizować go o meta pobrane z modułów typu newsy czy artykuły? Zawsze to zapytanie do bazy mniej - czy dać sobie z tym spokój? Jeden niewielki select niby nic, ale pomnożony razy n userów razy m odsłon...

IV. Podobnie jest ze stylami - jak wyżej, są style przypisane do całego serwisu, ale i takie które dotyczą tylko tabeli x w artykule y, no i mamy jeszcze podział na media

V. Templaty, panele, moduły - tu myślę że jest w miarę prosto, wystarczy cache z informacją, jakie moduły/panele/templaty przynależą się danej kategorii a pozostałe problemy zostały już opisane w pkt I.

Będę wdzięczny za wszystkie uwagi, sugestie etc.

[Pilsener]

Dziękuję za odpowiedź.

A po co męczyć parser?

- dlatego wymyśliłem, że np. listę kategorii i podkategorii wrzucam do tablicy, serializuję i zapisuję w zwykłym pliku tekstowym (xml jednak zajmuje sporo więcej), obróbkę już przetestowałem - nie ma większej różnicy, to musiałby być serwis chyba z kilkuset podkategoriami - ale dopisałem do planu, by w przyszłości zrobić cache dla każdej kategorii. Największy zysk jest na tym, że odpada zapytanie do bazy.

4. Jak odświeżać cache? Co jakiś czas skryptowo, cronem czy odpalać klasę/funkcję w określonych sytuacjach (np. edycja meta-danych jakiejś kategorii)? A może łączyć te metody, pozwolić wybrać userowi w PA?

W określonych sytuacjach.

- a mógłbyś to jakoś rozwinąć? Z cronem mam np. taki problem, że nie wszystkie hostingi go zapewniają i problematyczna mi się wydaje wygodna (automatyczna) implementacja tego. Najrozsądniejsze byłoby uzależnienie częstości aktualizacji cache'u od obciążenia serwera plus jakieś kolejkowanie i priorytety - ale to na przyszłość.

Cytat
jakoś nie widzę cache'owania tego, zbyt duża zmienność, zbyt duża liczba akcji i opcji - planuję zostawić jak jest.

No to cache'ujesz tak, jak wcześniej - przy edycji/dodaniu przeterminowujesz cache. A liczbę odwiedzin/etc. robisz co np. godzinę. Sam fakt zwiększenia licznika dopisujesz do jakiegoś loga i potem cronem zatwierdzasz aktualizację.

- no gdy ktoś coś dopisze na forum czy doda ocenę/komentarz do artykułu raczej nie chciałby tego zobaczyć po godzinie - a co z sortowaniem, porcjowaniem? Cache na każdą możliwą ewentualność? Wydaje mi się to pracą wręcz syzyfową, żeby np. takie forum jak to ocachować.

Możesz zrobić cache w postaci tabeli memory

- a mógłbyś powiedzieć o tym coś więcej? Pierwszy raz słyszę o tabelach memory.

A co ma do tego DB?

- wszystkie style trzymam w bazie gdyż umożliwia to łatwe zarządzanie nimi no i wychodzę z założenia, że do tego baza właśnie jest, dzięki temu widać od razu jakie style odnoszą się do jakich stron, w grę wchodzi też dziedziczenie styli do podrzędnych kategorii, podział na media - na plikach byłoby zbyt dużo zabawy z tym choćby dlatego, że ciężko byłoby ogarnąć relację wiele do wielu.

pliki, to nie jest jedyne rozwiązanie

- właśnie czytam, ale na razie postanowiłem zacząć od plików i od tego menu, jeśli efekty będą zachęcające to uderzę w inne rozwiązania, by mieć porównanie.