Uwaga! Od sierpnia 2017 forum jest w trybie tylko do odczytu.

Dlaczego? Dlatego, że społeczność TYPO3 przeniosła się na slack'a i stackoverflow:
  • Przeczytaj artykuł wprowadzający do slacka, w którym dowiesz gdzie i jak się zarejestrować.
  • Jeżeli masz pytania odnośnie Polskiej Społeczności TYPO3 zapraszamy na kanał slack'a #community-pl. Rozmawiamy tam w języku polskim.
  • Pytania dotyczące samego TYPO3 zadawaj po angielsku na stackoverflow oznaczając je tagiem "typo3". Następnie posługując się linkiem do tego pytania postaraj się zachęcić ludzi z kanału slack'a #typo3-cms lub bardziej pasujących kanałów tematycznych, żeby na nie odpowiedzieli.
  • Możesz też oczywiście zadawać pytania na slacku bez zakładania wątków na stackoverflow, ale wówczas wiedza ta nie jest indeksowana przez googla i część osób nie będzie chciała Ci z tego powodu pomagać.
  • Dla części osób dzielących się wiedzą ważne jest też budowanie reputacji na stackoverflow. Jest to kolejny powód dla którego powinieneś zadawać pytania na stackoverflow by zwiększyć swoje szanse na znalezienie odpowiedzi. Pamiętaj, żeby oceniać odpowiedzi!
Tematy bez nowych odpowiedzi

rozszerzenie i cache


Autor Wiadomość
Napisane: 16.09.2011 [16:39]
tomkraw1
admin
Twórca tematu
zarejestrowany: 14.07.2008
Posty: 530
Piszę rozszerzenie. Powiedzmy że to tabela z kwiatkami oraz nad nią selektor rodzajów kwiatków. Tabela jest sortowana i stronicowana (ext: pagebrowse).

Dane w tabeli zmieniają się dość dynamicznie więc strona z tym rozszerzeniem ma ustawione cache na 1 min a rozszerzenie: $pi_checkChash = true, $pi_USER_INT_obj = false.

Strona na początku generuje się poprawnie. Gdy użyję selektora rodzajów 1-szy raz to widzę pustą stronę z informacją, że ta strona zostanie wygenerowana za 30 sek. Po tym czasie strona sama się generuje i wszystko już gra. Jeśli od razu użyję sortowania lub stronicowania to jest ok.

Nie wiem gdzie szukać problemu. Co radzicie?


pozdrawiam
Tomek
Napisane: 16.09.2011 [18:43]
kss
zarejestrowany: 19.07.2007
Posty: 1341

Jażeli i tak czyścisz cache co 1 min to o wiele prostszym sposobem jest tutaj zmiana rozszerzenia z USER na USER_INT. Nie musisz wówczas dbać o cHash'a.


=======================================
t33k
Napisane: 18.09.2011 [09:50]
biesior
admin
zarejestrowany: 20.03.2008
Posty: 1709
Hm, przemyśl możliwość użycia EXT:enetcache, pozwala na obsługę cache'u we własnym pluginie i odnoszę wrażenie, że może Ci pomóc.

Ogólnie działa to tak, że na początku wtyczki sprawdzasz wszystkie parametry przekazane do wtyczki i budujesz z nich klucz, zatem jeśli np. wyświetlana 3 strona listy posortowana po nazwach kwiatków malejąco sprawdzasz, czy taki zestaw parametrów ma zbudowaną zawartość w enetcache i jeśli tak to ją wyświetlasz, jeśli nie to budujesz, zapisujesz do bazy i wtedy wyświetlasz... Jak mniemam Ty do klucza musiałbyś jeszcze dodać sprawdzanie timestampu najnowszego rekordu w wybranym zakresie i dzięki temu nie musiałbyś czyścić cache'u co minutę, bo enetcache sam zdecyduje, czy wtyczka ma być renderowana z cache'u czy od nowa.

TYPO3 Certified Integrator | TYPO3 Społeczność Polska

prv: ['] waiting for the miracle, for the miracle to come
Napisane: 18.09.2011 [10:24]
kss
zarejestrowany: 19.07.2007
Posty: 1341

Chyba zapomniałeś dodać, że samo entcache nic nie da jeżeli tak czy inaczej nie zbudujesz linków z poprawnymi cHashami albo nie przełączysz rozszerzenia w USER_INT.

Anyway ja zrobiłbym to tak:
1) Przełączam ext w USER_INT - patrzę czy przy zakładanym obciązeniu serwisu serwer nie dostaje zadyszki. Jeżeli wszytko działa płynnie to kończę na tym pkcie.

2) Jeżeli okazuje się obciążenia są zbyt duże, to i tak zostawiam exta jako USER_INT i próbuję wykorzystać entcache do cachowania cięższych partii.





=======================================
t33k
Napisane: 18.09.2011 [11:27]
biesior
admin
zarejestrowany: 20.03.2008
Posty: 1709
Cóż dałem Tomkowi sugestię bez zagłębiania się w szczegóły, oczywiście wtyczka wyposażona w enetcache musi pracować z pominięciem cache'u TYPO3, więc najszybciej to osiągnąć właśnie z USER_INT z drugiej strony niezależnie od obciążenia serwera myślę, że warto go zastosować, bo wówczas masz kontrolę nad odświeżaniem cache'u tylko po wystąpieniu określonych okoliczności, więc jeśli w ciągu minuty po dodaniu nowego kwiatka na stronę wejdzie 1000 ogrodników to otrzymają oni listę z cache'u, chyba, że dodasz nowy kwiat wówczas 589 user poczeka na regenerację cache'u a następnych 411 znów dostanie z cache'u.

Przy czystym USER_INT za każdym razem lista będzie renderowana, co przy skomplikowanych regułach wybierania rekordów może być zabójcze (nawet jeśli taka sytuacja trafia się raz na sezon ogrodniczy)

IMHO skórka warta wyprawki.

TYPO3 Certified Integrator | TYPO3 Społeczność Polska

prv: ['] waiting for the miracle, for the miracle to come
Napisane: 18.09.2011 [12:08]
kss
zarejestrowany: 19.07.2007
Posty: 1341
"biesior" napisał/a

IMHO skórka warta wyprawki.


Wg mnie zawsze warto spojrzeć na obciązenie. Jeżeli serwis będzie miał 100 unikalnych userów na dzień, to nie widzę sensu w optymalizowaniu czegokolwiek. No chyba, że dla przyjemności.

Jeżeli obciązenie z czasem wzrośnie to zamawiający zawsze może dopłacić za usługę optymalizacji.



=======================================
t33k
Napisane: 18.09.2011 [13:14]
kss
zarejestrowany: 19.07.2007
Posty: 1341
"biesior" napisał/a

wtyczka wyposażona w enetcache musi pracować z pominięciem cache'u TYPO3


A dlaczego z pominięciem cache TYPO3?


Nawet jeżeli używasz cache TYPO3 to używanie entcache może być mocno wskazane.

Mamy 1000 newsów.

Wyobraź sobie widok pojedynczy newsa, który jest cachowany standardowo. W cachu "cachingframework_cache_pages" jest więc 1000 rekordów scachowanych stron. Plus dziesiątki stron widoków list.

Teraz wyobraż sobie sytuację, że edytujesz nazwę jednego z newsów. Standardowo, żeby zmiana odniosła sukces musisz wyczyścić cache wszytkich newsów - widoków pojedynczych i widoków list.

Teraz załóżmy, ze korzystamy z entcache.

1. Wystąpienie newsa na jakiejkolwiek ze stron tagujemy (w widokach list i w pojedynczym)
2. Jeżeli news o uid=78 zmienił tytuł to wysyłamy do entcache polecenie: "usuń rekordy z tabeli "cachingframework_cache_pages" tam gdzie występował news o uid 78".

Wynik?
Zostaną usunięte te rekordy z tabeli "cachingframework_cache_pages" gdzie występował tytuł newsa. Więc nie tylko widok pojedynczy samego newsa, ale też widoki list na których występował a także inne widoki pojedyncze na których mógł występować w newsach powiązancyh.

Żadne inne strony z widokami list i widokami pojedynczymi nie są usuwane z "cachingframework_cache_pages".
Oszczędności przy dużej bazie rekordów gigantyczne.


Podsumowując oszczędności są przy obydwu sytuacjach: zarówno kiedy budujesz z cHashami albo nie bawisz się w pełny cache i używasz tyko USER_INT


=======================================
t33k
Napisane: 20.09.2011 [14:17]
tomkraw1
admin
Twórca tematu
zarejestrowany: 14.07.2008
Posty: 530
Dzięki za sugestie. Rozszerzeniu enetcache przyjrzę się.

Przełączam rozszerzenie na USER_INT więc $pi_checkChash = FALSE, $pi_USER_INT_obj = 1 i wszystkim linkom tworzonym przez rozszerzenie dałem $cache = 0. Wciąż pojawiają mi się komunikaty "Page is being generated"? Więc coś jest jeszcze źle.

We właściwościach tej strony nie mam włączonego "no_cache" oraz mam domyślny czas cacheowania. W konfiguracji dla tej strony TS podałem:
TYPOSCRIPT
config {
  sendCacheHeaders = 0
  cache_period = 0
  no_cache = 0
}


Czy może mi sprawiać cacheowane rozszerzenie pagebrowse albo co źle robię?


pozdrawiam
Tomek
Napisane: 21.09.2011 [08:56]
kss
zarejestrowany: 19.07.2007
Posty: 1341
"tomkraw1" napisał/a

Wciąż pojawiają mi się komunikaty "Page is being generated"? Więc coś jest jeszcze źle.


Ogólnie ten komunikat nie powinien się już pojawiać, bo od wersji 4.3 chyba, zostało to inaczej rozwiązane - musiałeś je przywrócić przez nieodpowiednie ustawienia w localconf.php

Ale generalnie on pojawia się wówczas, kiedy:
a) strony nie było jeszcze w cache
b) zostało wysłane żądanie A do strony X - strona zaczyna być generowana - załóżmy, ze trwa to 10 sek
c) w ciągu następnej sekundy wysłane zostaje żądanie B do strony X. To żądanie jest już przetrzymywane z komunikatem "Page is being generated", ponieważ TYPO3 czeka, żeby zwrócić wynik strony wygenerowanej przez żądanie A. Co x sekund strona z żądania B jest odświeżana, żeby sprawdzić czy strona z żądania A została już umieszczona w cache, żeby móc ją wyświetlić.

Tak działa ten mechanizm, a dlaczego zachowuje się tak w Twoim przypadku nie mam pojęcia. Nigdy nie miałem problemów podobnych do Twojego, tzn. z "Page is being generated" przy własnym ext.


Co do USER_INT
Pewnie masz funkcję t3lib_extMgm::addPItoST43 w pliku ext_localconf.php. Jej czwarty parametr mówi czy ext jest cachowany czy nie. Ustaw ten czwarty parametr na 0.

To czy ext jest USER czy USER_INT można też sterować poprzez zmianę z poziomu TS, np.
plugin.tt_news = USER_INT

Ustaw podobnie w TS dla swojego ext'a.


A teraz - żeby sprawdzić czy Twój ext jest w USER_INT zajrzyj do rekordu wygenerowanego w tabeli cachingframework_cache_pages (lub cache_pages) i w wygenerowanym i umiescznym tam źródle strony poszukaj wystąpienia swojego exta. Jeżeli jest on USER_INT to w miejscu gdzie miał być kod exta będzie marker, nie pamiętam teraz dokładnie, coś w stylu <!-- USER_938453458 -->.

Jeżeli natomiast jest zwykły kod html z Twojego exta to znaczy, że USER_INT nie działa.



=======================================
t33k
Napisane: 21.09.2011 [14:21]
tomkraw1
admin
Twórca tematu
zarejestrowany: 14.07.2008
Posty: 530
Dodanie do setup.txt jako 1-szej linijki
TYPOSCRIPT
plugin.tx_mykwiatki_pi1 = USER_INT

Spowodowało nie pojawianie się owego komunikatu.

Sprawdziłem t3lib_extMgm::addPItoST43 w ext_localconf.php $cache to 5-ty parametr i ustawiłem 0.

W tabeli cache_pages w polu cache_data w rekordzie z id strony na której jest plugin jest taki bloczek
HTML
<!--INT_SCRIPT.XXXX-->
gdzie XXXX to chyba md5 czegoś (32B) więc chyba o to chodziło.

Praca idzie we właściwym kierunku więc WIELKIE DZIĘKI !

pozdrawiam
Tomek