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.

A po co męczyć parser?


Bez sensu. Po co gotować procesor?


Osobny cache dla każdej kategorii.


W określonych sytuacjach.


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


Możesz zrobić cache w postaci tabeli memory. Połączenie i tak będziesz miał pewnie za każdym razem, nie zaszkodzi, a zapytanie wykona się piorunem.


A co ma do tego DB?


Jeśli trzymasz w plikach, to się nawet nie cykaj. [;

PS. Był ostatnio temat o cache'owaniu; pliki, to nie jest jedyne rozwiązanie.

Dziękuję za odpowiedź.
- 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.

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

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


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

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

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

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


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 komentarz, to nie, ale zerknij na czyiś profil na tym forum - jest pewna gwiazdka. [;


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


To poczytaj. [; Wtedy porozmawiamy.


Posiedziałbyś przy IPB, który również trzyma style w bazie, to też byś przeklinał. Baza DANYCH, a nie stylów.


Trochę niezrozumiałem?


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

Wielkie dzięki za pomoc.

Właśnie skończyłem testować menu na zserializowanej tablicy w pliku - wygląda bardzo obiecująco (przyśpieszenie wyraźne), obmyślam właśnie teraz mechanizm aktualizowania cache, wpadłem na pomysł, by wykorzystać tutaj mechanizm uprawnień z jego listą akcji (typu kategorie->edycja, kategorie->dodawanie) - jak można sprawdzać dla każdej akcji uprawnienia, to można będzie podpiąć też aktualizację określonych cache dla danej akcji - wystarczy trochę rozbudować.

- racja, ale ja wciąż martwię się o obciążenie pamięci, bo jednak "przemielenie" tych wszystkich plików cache to może i problem dla dysku nie jest, ale dla procka i owszem - dlatego wolałbym (jak się da) uniknąć sytuacji, w której mam pod sobą kilka tysięcy plików cache

- właśnie skończyłem, nie mam pytań odnośnie tabel memory, pozostaje przetestować ich zachowanie w praktyce, może słabo szukałem, ale wydaje mi się, że to nie jest popularna metoda, mało jest publikacji takich jak ta:
http://blog.chylek.pl/tag/memory/ - a chyba szkoda?

No to postaram się trochę wyjaśnić: jedna kategoria może korzystać z wielu styli, a jeden styl może być wykorzystany w wielu kategoriach, style są katalogowane, każdy ma id, nazwę, opis oraz właściwości (takie jak np. dziedziczenie - czyli czy jest wczytywany dla kategorii podrzędnych, media - jak ktoś chce ustawić oddzielny styl dla wydruku itp.), generalnie założenie jest takie, że style są generowane dynamicznie (może od tego powinienem zacząć). Skoro i tak informacje o stylach muszą być gdzieś zapisane, to stwierdziłem, że najwygodniej to wszystko zrobimy w bazie - dzięki temu szalony webmajster który tego używa wie, jakie style do czego się odnoszą, ma wszystko na tacy, nie musi analizować całego pliku .css, tylko jego fragment, wchodząc np. do kategorii filmy/sensacyjne ma listę styli, które ta kategoria dziedziczy oraz styli przypisanych do tej kategorii - dochodzą jeszcze style z klocków dołączonych do tej kategorii

- właśnie na tej prędkości najbardziej mi zależy - założenie jest takie, że ma płynnie działać nawet na darmowym hostingu w Burundi, i nie chodzi tutaj raczej o jakiś duży serwis, lecz dużo małych serwisów (np. żeby zaśmiecić gugla pod zapleczówkę, a do tego celu przecież nie będziemy korzystać z dedykowanych serwerów itp.). O samym cache też niewiele niestety można znaleźć w książkach, a widzę tu olbrzymi potencjał.

To jest najmniejszy problem - dzisiaj wszystkie dyski diałają z opcją DMA, więc nie opowiadaj o obciążeniu CPU. Bardziej bym się doczepił do Twojego początkowego pomysłu z kompresją. Unixowe systemy plików są bardzo wydajne, nie przejmuj się tym banałem. [;


A po co pisać o czymś, co praktycznie niczym się nie różni od tego, jak obsługujesz normalne tabele SQL? Tylko przy resecie tabela jest czyszczona, a tak, to AFAIR żadnych różnic nie ma.


SHM, APC, eAccelerator (tak, tak, jest funkcja udostępniająca SHM w ramach akceleratora). Ale na darmowym hostingu zapomnij o takich dobrodziejstwach...


Trochę przemodziłeś. [; Ale najlepiej by było po prostu każdy styl cache'ować na HDD.

Tak ogólnie, daruj sobie hostingi bez akceleratorów; przy większym obciążeniu różnica jest dość wyraźna.