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.

[erix]

- 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.

Zserializowana tablica będzie najlepsza; nie ma formatu, który by się szybciej parsował, wg moich informacji.

- 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ść.

Cron nie ma tu sensu. Np. jak masz gdzieś newsa, to cache'ujesz go do pliku news_1.cache i ustawiasz mu nieskończoną ważność. Gdy edytujesz newsa - cache jest kasowany i zastępowany nową zawartością. Nie martwisz się wtedy o nic.

Zresztą, uzależnienie cache'u od crona jest nieco nienaturalne - dane aktualizujesz nawet wtedy, gdy się one nie zmienią.

- 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?

No komentarz, to nie, ale zerknij na czyiś profil na tym forum - jest pewna gwiazdka. [;

Cache na każdą możliwą ewentualność? Wydaje mi się to pracą wręcz syzyfową, żeby np. takie forum jak to ocachować.

Wiele systemów tworzy osobny cache per zapytanie. Dzisiaj to nie ma znaczenia, ile miejsca na dysku zżera.

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

To poczytaj. [; Wtedy porozmawiamy.

- 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.

Posiedziałbyś przy IPB, który również trzyma style w bazie, to też byś przeklinał. (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) Baza DANYCH, a nie stylów.

- na plikach byłoby zbyt dużo zabawy z tym choćby dlatego, że ciężko byłoby ogarnąć relację wiele do wielu.

Trochę niezrozumiałem?

- 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.

W sumie zmienia się tylko lokalizacja zapisu i prędkość działania.