Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: cachowanie w php
Forum PHP.pl > Forum > PHP > Pro > Archiwum Pro
fryk
Jak myslicie? Strony generowane sa dynamicznie + optimizery + kesze itp., czy engine generuje w okreslony sposob statyczne strony?

Siadam wlasnie do silnika serwisu, ktory moze spotkac ogromny trafik wiec nie wiem w ktorym kierunku pojsc.

Nie mam czasu na doglebne poznanie materii a projekt musze ukonczyc jak najszybciej a chcialbym zeby jak najdluzej "pociagnal" smile.gif

Bede ogromnie wdzieczny za cenne rady, ktorymi wiem ze dysponujecie winksmiley.jpg

POZDRAWIAM!
crash
Powinieneś dostać pstryczka w ucho tongue.gif za pisanie w tym dziale o takich pierdołach...
enceladus
Cytat(crash @ 2005-08-10 22:42:42)
Powinieneś dostać pstryczka w ucho tongue.gif za pisanie w tym dziale o takich pierdołach...

Dlaczego questionmark.gif? Temat może być ciekawy i bardzo rozwojowy - tylko tytuł i treść skonstruowane fatalnie smile.gif

Wbrew pozorom pisanie kodu to połowa sukcesu. Przy dużym ruchu jeden serwer nie wytrzyma nawet z najbardziej zoptymalizowanym kodem, bo np. dyski będą zbyt wolne itp.
Z moich doświadczeń:
1. Odzielny serwer (co najmniej w znaczeniu aplikacji) do obrazków i wszystkiego co statyczne - np. thttpd - wyraźnie odciąża maszynę. Apache to straszna krowa zjadająca zasoby systemowe przy takich danych.
2. Stosowanie reverse proxy - uzupełnia funkcjonalnie serwer do treści statycznych, dodatkowo pozwala wprowadzić pewne elementy bezpieczeństwa - dopuszczamy do apache tylko requesty typu POST, GET itp.
3. Jeśli dysponuje się wieloma maszynami, warto rozproszyć bazę przez sotoswanie oddzielnych maszyn do SELECT-ów i innych do UPDATE, INSERT - te do których robiony jest upd, ins replikują dane do tych z których idą selecty.
4. Warto zastanowić się nad rezygnacją z apache - jest uniwersalny ale przez tą uniwersalność przerośnięty. Budując dedykowany serwer WWW duża część tej uniwersalnej funkcjonalności jest zupełnie zbędna. Dodatkowo apache stosuje forkowanie do tworzenia nowych instacji, serwery wielowątkowe są wydajniejsze. Przykładem niech będzie lighttpd ( http://www.lighttpd.net )
5. Wazny tez jest dobór sprzętu, przy pewnym poziomie ruchu na serwisi do stosowania nadają się tylko szybkie dyski SCSI, odpowiedni RAID, procesory serii XEON też wyraźnie poprawiają wydajność ...
splatch
Realizowałem podobny projekt.

Przy dodawaniu do bazy nwoego rekordu w kolumnie "generate" wstawiana była domyślna wartość, czyli 1. To samo przy modyfikacji wiersza - ustawienie w kolumnie generate jedynki.
[RE]Generowanie było realizowane podczas najmniejszego ruchu w sieci (czyt. późno w nocy) w kilkunastu cyklach. Jeden cykl tworzył/modyfikował 100 prac. Skrypt mógł być automatycznie odpalony z crona albo poprzez przeglądarkę (odświerzał się automatycznie do ukończenia generowania).
Nie jest to wyszukany sposób na obejście obciąrzenia, ale skrypt ten znacznie zmniejszał obciążenie serwera, ponieważ przepracował ciężko 30 minut w nocy i potem cały dzień odpoczywał...
treewood
Opracowalem kiedys dla wlasnych potrzeb klase "Cache", ktora wspolpracuje z "TplParser" (umiescilem skrypt do niego w dziale skrypty php).

Kod Html na podstawie template'ow wciskany jest do jednej zmiennej i na koncu pliku wyswietlany np. echo $sContent;

Do pliku np. "cache.txt" laduje wszystkie REQUEST_URI oraz sciezke do cache'owanego pliku, ktory ma sie wyswietlic jesli zostal wykonany jakis kod HTML.

W ten sposob cache generuje sie na zywo. Ktos wyszukuje to wpierw wygeneruje na bazie odpowiednie zapytanie i zostanie mu wyswietlony wynik a miedzyczasie zapisuja sie do odpowiedniego pliku dane.

Jesli ponownie ktos wykona podobne wyszukiwanie to zamiast powtornie obciazac baze to po prostu pobierany jest wygenerowany plik z kodem HTML.

Oczywiscie trzeba opracowac tez kilka wyjatkow bo co jak ktos przesyla formularz POST'em itd itp. Obeszlem to tak, ze po prostu do tablicy spisuje jakie akcje maja sie nie cache'owac i tyle.

Dzieki cache'owaniu doszlo do tego, ze czasami nie musimy sie wogole laczyc z baza danych a kod jest 10 x szybciej generowany.

Problem tez pojawil sie w przypadku gdy niektore czesci kodu maja sie generowac dynamicznie np. bannery, losowy artykul itd.
Obeszlismy to tak iz do wygenerowanych plikow HTML wciskalismy po prostu zmienne i w czasie wyswietlania parsowalismy odpowiednio plik, ktory pozniej zamienial zmienne kod.

Przykladow wykonana akcja "index.php?p=productsList":
  1. <?php
  2.  
  3. // definiowanie co ma sie nie generowac w cache
  4. $oCache->setExceptions( Array( 'productsShow', 'productsForm' ) );
  5.  
  6. // zwracanie losowego bannera
  7. $sBanner = throwRandomBanner( );
  8.  
  9. // sprawdzanie czy istnieje cache'owany plik
  10. if( $oCache->checkCache( $_GET['p'] ) === TRUE ){
  11.   echo $tpl->dHtml( $oCache->throwFile( $_GET['p'] ) );
  12. }
  13. else{
  14.  
  15.   /*
  16.   * To tutaj laczymy sie z baza, wyswietlamy dane z bazy itd
  17.   */
  18.  
  19.   $content = $tpl->tHtml( 'page.tpl' );
  20.  
  21.   // sprawdzanie czy wykonana akcja np. $_GET['p'] czy $_SERVER['REQUEST_URI'] jest w wyjatkach
  22.   if( $oCache->checkException( $_GET['p'] ) === FALSE ){
  23.  
  24.     // cache'owanie
  25.     $oCache->cacheHtml( $content, $_GET['p'] );
  26.   }
  27.  
  28.   echo $content;
  29. }
  30.  
  31. ?>


Oczywiscie to tylko przyklad jak cos rozwiazac. Niekoniecznie to tak wyglada u mnie gdyz pisalem to nie patrzac wogole do kodu konkretnej realizacji takiego projektu.

Jesli wykonamy jakas akcje zapisu/zmiany w bazie to wystarczy jedynie usunac cala zawartosc lub czesc pliku cache.txt i wszystko bedzie generowane od poczatku

Musze dodac iz jest to rozwiazanie dla konkretnych przypadkow nie wszedzie sie sprawdzi. Wychodzilismy z zalozenia, ze wazne jest proste rozwiazanie zakladajac, ze wszystko co sprawi iz cos bedzie mniej obciazalo serwer jest "dobre".
wewior
oczywiscie bardzo przydatne sa wszelkie systemy cachujace od strony serwera takie jak squid'y czy cacheflow'y super sprawa jest tez podzial ruchu przy pomocy pomocy kilku serwerow emisyjnych tylko pytanie czy sa takie mozliwosci, jesli tak to jak najbadziej
kolejne pytanie jaka baza danych? bo tutaj tez moze byc troche mozliwosci np cachowania zapytan
splatch
W moim przypadku był optymizer Truck MM Cache, który wywalał cały skrypt. Przy generowaniu statycznych stron powstawał efekt zapętlonej ramki i trzeba było go wyłączyć...
SongoQ
Cytat
3. Jeśli dysponuje się wieloma maszynami, warto rozproszyć bazę przez sotoswanie oddzielnych maszyn do SELECT-ów i innych do UPDATE, INSERT - te do których robiony jest upd, ins replikują dane do tych z których idą selecty.

Troche mylisz pojecia, zobacz na rozwiazanie ORACLE 10g.

Cytat
Przy dodawaniu do bazy nwoego rekordu w kolumnie "generate" wstawiana była domyślna wartość, czyli 1. To samo przy modyfikacji wiersza - ustawienie w kolumnie generate jedynki.
[RE]Generowanie było realizowane podczas najmniejszego ruchu w sieci (czyt. późno w nocy) w kilkunastu cyklach. Jeden cykl tworzył/modyfikował 100 prac. Skrypt mógł być automatycznie odpalony z crona albo poprzez przeglądarkę (odświerzał się automatycznie do ukończenia generowania).

Takie cos mozesz zrealizowac bezposrednio na bazie danych nie ruszajac systemu i php.
splatch
@SongoQ jeśli możesz daj jakiś przykład... jestem ciekaw w jaki sposób można to zrealizować. smile.gif
SongoQ
Cytat
@SongoQ jeśli możesz daj jakiś przykład... jestem ciekaw w jaki sposób można to zrealizować.

Tylko ze to na hehe MySQLu nie zrobisz. Np w ORACLE sa triggery wyzwalane roznymi zdarzeniami, nie tylko UPDATE, INSERT, DELETE lecz rowniez czasowo i innymi akcjami.

PG jeszcze takich rzeczy sie nie dorobil z tego co mi wiadomo, mozna by wykorzystac akcje userow, ale to trzeba miec ruch na tyle spory aby sie to oplacilo, wiec w bazach ktore nie maja tego w sobie to bez zewnetrznych wyzwalaczy sie nie obejdzie.
splatch
Cytat
Tylko ze to na hehe MySQLu nie zrobisz. Np w ORACLE sa triggery wyzwalane roznymi zdarzeniami, nie tylko UPDATE, INSERT, DELETE lecz rowniez czasowo i innymi akcjami.

PG jeszcze takich rzeczy sie nie dorobil z tego co mi wiadomo, mozna by wykorzystac akcje userow, ale to trzeba miec ruch na tyle spory aby sie to oplacilo, wiec w bazach ktore nie maja tego w sobie to bez zewnetrznych wyzwalaczy sie nie obejdzie.

Zapewne wiesz, że Postgresie są triggery razem z regułami. To, że można stworzyć sobie wyzwalacz czy tylko regułę (wystarczają w zupełności gdy operuje się na tabelkach) to dla mnie nic nowego. Myślałem, że jest jakiś ciekawszy sposób...
Z innej beczki, można by wykorzystać rozszeżenie umożliwiające wykorzystywanie funkcji php w procedurach PG..
fryk
Dziekuje za odpowiedzi ale troche sie balagan zrobil.

Moze tak: na logike wygrywa statyka - czyli engine generujacy statyczne strony. Tak na pewno dzialaja duze serwisy. Przy serwisie aukcyjnym (zblizony model do mojego projektu) nad takim enginem trzebaby troche posiedziec.

Z drugiej strony phpa mozna doladowac cachem - truck mmcache itp - lub czyms w tym stylu.

PROBLEM w tym, ze nie orientuje sie jakiego rzedu sa roznice w wydajnosci powyzszych rozwiazan.

Niezmiernie bylbym wdzieczny za jakies realne liczby wraz ze specyfikacja srodowiska itp.

Byc moze niepotrzebnie sie wogole glowie smile.gif

Pozdrawiam serdecznie!
aleksander
pozwolicie, że zmienie nazwe tematu na bardziej odpowiednią winksmiley.jpg

Od siebie dodam, że mając framework z Intercepting Filter keszowanie jest banalnie proste. Robie sobie PostFiltr Cache który wyciąga z HttpResponse zawratośc, i keszuje jąsmile.gif PreFiltr Cache sprawdza czy kesz dla danej strony istnieje i jeżeli tak, to go wyswietla.

pozdrawiam
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2024 Invision Power Services, Inc.