PHPTAL o cache owaniu slow kilka

No to naturalnie keszujesz per-user. W takim razie keszuj tylko listę ID-ków danej kategorii/widoku. Albo bez cache - podciagaj tylko z bazy to, co potrzebne do danej strony po ID-kach. Dodanie newsa nie musi burzyć cache leadów, prawda? Gorzej, jak masz np. linki prev/next w artykule W zasadzie to chyba trzeba by zrobić jakieś testy - może to przebudowywanie listy wpisów po edycji wcale nei jest na tyle kosztowne, aby sie tym w ogóle zajmować?
Przy kilkudziesieciu tysiacach uzytkownikow tez sie to stosuje? Cholera, spory ten cache wowczas. Poza tym jesli chcialo by sie udostepnic uzytkownikom podglad zalogowanych uzytkownikow/znajomych, to sie sprawa komplikuje (chyba ze stosujemy cache 10 minut bez innych warunkow), no chyba ze JS wtedy zatrudniamy.

Tylko w moim przypadku jest tak zagmatwane, ze jeden nius moze nalezec do kilku kategorii, a do tego na jednej stronie sa wyswietlane niusy z kilku kategorii, takze dodajac jeden artykul trza by bylo odswiezyc kesz dla wszystkich wikodokow kategorii, do ktorych przypisalo sie niusa. Niby liczba widokow jest okreslona i raczej za czesto sie nie zmienia, ale liczylem, ze jakos latwiej uda sie to rozwiazac, bo tak jak wspominalem, dodajac jednego niusa w obecnym projekcie trza by wyczyscic cache wszystkich stron, bo:
podzial niusow na strony przed dodaniem (kategoria: wszystkie):
str.| 1 2 3 4 5 6 7 8 9 10 ----+----------------------------------------- | 47 42 37 32 27 22 17 12 7 2 | 46 41 36 31 26 21 16 11 6 1 | 45 40 35 30 25 20 15 10 5 | 44 39 34 29 24 19 14 9 4 | 43 38 33 28 23 18 13 8 3
po dodaniu niusa 48 (wszystkie)
str.| 1 2 3 4 5 6 7 8 9 10 ----+----------------------------------------- | 48 43 38 33 28 23 18 13 8 3 | 47 42 37 32 27 22 17 12 7 2 | 46 41 36 31 26 21 16 11 6 1 | 45 40 35 30 25 20 15 10 5 | 44 39 34 29 24 19 14 9 4
przed dodaniem (kategoria 1)
str.| 1 2 3 ----+----------- | 46 32 11 | 44 28 5 | 41 25 2 | 37 22 | 33 16
po dodaniu (kategoria 1)
str.| 1 2 3 ----+----------- | 48 33 16 | 46 32 11 | 44 28 5 | 41 25 2 | 37 22

Nie musi burzyc, a linki prev/next w miare szybko sie wyciaga z bazy, wiec tutaj tez duzego problemu nie ma. Najwiekszy problem mam z wyciaganiem okreslonej liczby niusow z kilku kategorii. skocz.pl/p.c.b-d - tutaj link do watku na pl.comp.bazy-danych, o ktorym wspominalem wczesniej - moze tu sa lepsi specjalisci (z calym szacunkiem dla osob odpisujacych mi na p.c.b-d) i ktos bedzie w stanie zasugerowac jakies rozwiazanie.
Przy okazji zapytam - czego uzywacie do cachowania zapytan mysql? Ja czas jakis nierozwijane od dawna dosyc), jednak gdy poczytalem o PHPTAL myslalem, ze to mi wystarczy. Tutaj chyba cachowanie zapytan by sie zdalo bardziej. OPD ma cachowanie, jednak nie obslugujace prepare

Poczekam dzien (moze ktos w miedzyczasie cos jeszcze podpowie) i sie za to wezme. Troche niechetnie do tego podchodzilem wczesniej, bo jak wspomnialem - dodanie jednego niusa powoduje spore zmiany w kilku miejscach.
Pozdrawiam

Jak w takiej sytuacji sprawdzac, kiedy nius byl ostatnio modyfikowany? Pobierac date zapytaniem z bazy? Cacheowac zapytania? A moze jakies inne rozwiazanie? -setTemplate('news.html'); -cleanUpCache(); -setTemplate('mainnews.html'); -cleanUpCache();
jednak nie chce to dzialac i czysci cache tylko pierwszego pliku. Da sie to jakos za jednym razem zrobic? Można pobierać z bazy tylko informację, czy newsy się zmieniły - zapytanie nie musi być dokładne, musi tylko dawać inną wartość za każdą zmianą. Jeśli masz jakiś strasznie skomplikowany system newsów, to zrób sobie osobną tabelę z datami i trigger, który będzie ją aktualizował.
Jak tabela ze zdenormalizowanymi danymi brzmi źle, to możesz te dane trzymać w memcached albo apc_store().
Oops, to bug. Obejściem jest tworzenie nowej instancji klasy PHPTAL dla każdego template'u (to nie jest kosztowne).