![]() |
![]() |
![]()
Post
#1
|
|
![]() Grupa: Zarejestrowani Postów: 1 590 Pomógł: 185 Dołączył: 19.04.2006 Skąd: Gdańsk Ostrzeżenie: (0%) ![]() ![]() |
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. |
|
|
![]() |
![]()
Post
#2
|
|
![]() Grupa: Zarejestrowani Postów: 1 590 Pomógł: 185 Dołączył: 19.04.2006 Skąd: Gdańsk Ostrzeżenie: (0%) ![]() ![]() |
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ć. Cytat Wiele systemów tworzy osobny cache per zapytanie. Dzisiaj to nie ma znaczenia, ile miejsca na dysku zżera - 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 ![]() Cytat To poczytaj. [; Wtedy porozmawiamy. - 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? Cytat Trochę niezrozumiałem? 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 ![]() Cytat W sumie zmienia się tylko lokalizacja zapisu i prędkość działania. - 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ł.
|
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 25.06.2025 - 11:59 |