Nie wiedziałem czy napisać to tu czy w dziale o php. Jeśli źle wybrałem to sorka i prosze o przeniesienie.

Ostatnio dużo zastanawiam się nad cache, jak to jest zbudowane w dużych serwisach. Weźmy na przykład serwis grono.net/fotka.pl. Miliony wpisów w bazie, miliony odwiedzić. Jak w taki dużych serwisach zorganiozwane jest cache ? Każde zapytanie ma swoje cache ? Prosił bym o jakieś dokładne informacje od osób orientujacych sie w temacie.

Pozdrawiam.

memcached

Nie wiem jak sprawa się ma w przypadku podanych przez Ciebie serwisów, jednak z doświadczenia wiem, że najlepszym rozwiązaniem jest generowanie treści statycznej, która następnie jest prezentowana użytkownikowi. Wszystkie dynamiczne operacje są wykonywane w ostateczności. Mówiąc prościej. Generuje się pliki HTML, które są wyświetlane użytkownikom. W przypadku zmian (np dodanie zdjęć, edycja profilu, nowe newsy, itd), plik HTML jest generowany ponownie. W najgorszym wypadku, gdy taki plik się nie utworzy, uruchamia się skrypt PHP/ASP/JSP, który to mieli i wyświetla.
Oczywiście nie należy zapominać o cache w bazie danych i na serwerze. Tam też dzieje się magia

Czyli tak, w modelu do bazy danych dodać cache oraz całą stroną cachować za pomocą jakiegoś narzędzia ?

@normanos - Memcache wydaje mi się ciekawe, ale nie każdym serwerze jest.

Sam serwer bazy danych oferuje cache-owanie wyników zapytania, przez co każde kolejne zapytanie jest wykonywane znacznie szybciej. Jednak nie jestem ekspertem w dziedzinie baz danych, więc nie pomogę za bardzo w tym temacie.
Dodatkowe cache-owanie zapytań może się przydać. Dzięki temu nie będziesz nawet łączył się z bazą danych.

@Moli: pytasz się o mega serwisy, a potem mi coś mówisz o hostingach

No to był przykład, chodziło mi o o jak obsłużyć zapytania do bazy jeśli jest tyle redkordów a nie to czy maja memcachce Myślałem nad czymś takim:
- Sprawdza czy istnieje plik cachu html (czyli już gotowy kod html z szablonem oraz wstawionymi elementami).
- Jeśli jest wczytuje go i konczy prace.
- Jeśli nie, sprawdza czy jest cache zapytania do bazy
- Jesli jest, tworzy cache html i wyswietla go
- Jeśli nie ma, pobiera wpisy z bazy normalnie, oraz tworzy cache bazy.

Dobre bedzie takie wyjście ?

batman: cache jest wykorzystywany tylko gdy kolejne zapytanie jest DOKŁADNIE takie samo jak wywołane wcześniej. Przynajmniej tak jest w MySQL.

@seaquest
O to mi właśnie chodziło. Za duży skrót myślowy mi wyszedł

dobre do jakiegoś momentu bo przy takiej (podales przyklad fotki) ilosci danych tyle keszu moze byc problematyczne (i/o).

lepiej też by było trzymać same dane w keszu a nie całe htmle. te przy takich ilosciach zajmą ci ogromne duzo miejsca, a samo podstawienie danych do szablonu to przeciez niezauwazalne wartosci. poza tym jak dobrze napiszesz sobie klasę do takiego keszu obiektów to potem tylko zamienisz sterowniki i np. z keszu plikowego w sekundke przejdziesz na memcached. nie mówiąc już o jakiś zmianach w ogolnym htmlu strony. ja w kazdym razie jestem przeciwnikiem keszowania calych htmli, dla mnie nie jest to sensowne rozwiazanie.

Hm, myślałem ostatnio o cache'owaniu, ale mam kilka wątpliwości...

Na jak długo tworzyć cache? Jak sprawdzać czy w między czasie nie powinien powstać nowy cache (aktualizacja danych)?

Na tyle ile ci potrzeba. Cache konfiguracyjny moze byc np. na dzien, a cache z newsami, np, na pol dnia. Jak to mowia: zalezy jak lezy.

Jesli dodajesz nowego newsa, to czyscisz cache newsow. Proste. Analogicznie wszystko inne

@normanos
W widokach gdzie są dynamiczne treści, mogę usunąć cache. Tam gdzie są dynamiczne, ale już mniej ważne, mogę ustawić czas trwania cache a tam gdzie mam stały, pobrany z template + baza + jakieś dodatki widok, cachuje (też na określony czas). Robiłem małe testy z tym i przyśpiesza bardzo widocznie. Trzeba będzie tylko dobrze dobrać widoki w których mogę stosować cache, ale już zadanie oddzielnie do każdego projektu

Ja stosuję prostą zasadę: średnia(przewidywana) częstotliwość zmienności danych / 2.

Ale w przypadku takich cache jak np. profil uzytkownika, mozna je usuwac tylko po zapisie nowych danych tego usera. Wtedy zyskujemy

Na jak najdłużej. Dopiero zmiana w treści powinna wymusić odświeżenie zawartości cache.

niekoniecznie. są sytuacje w których zmiana treści wymusiła by non-stop zmiane keszu i tym samym podważyła jego sens (a raczej zamiast poprawić by tylko pogorszyła). w takich przypadkach stosuje się kesz na dany czas.

Skoro zmiana treści występuje w tak krótkich odstępach czasu to nie ma sensu wówczas w ogóle korzystać z mechanizmów cache-owania, ponieważ tak jak napisałeś, spowoduje to spadek wydajności. Poza tym tworzenie i usuwanie zbuforowanych plików powinna odbywać się nie w momencie wejścia na stronę. Tworzenie cache-u powinno odbywać się w momencie zmiany treści (np dodano news), po stronie tzw. admina.

@batman: pozwolę się z tobą całkowicie... NIEzgodzić Może rzucę jakimis przykładami aby było łatwiej:

choćby bardzo częsta sprawa => zliczanie danych z kategorii, ot powiedzmy, że mamy imageshacka z menu

Architektura (2324342525 zdjec)
Krajobraz (45352632362 zdjęc)

itd. robienie countów jest masakryczne (używa się też często dodatkowego pola w sql i inkrementuje ale chciałbym uogólnić przykład) a zmiana keszu przy dodaniu fotki (n-fotek na sekunde) mija się z celem. Nie mówiąc o tym, że sytuacja nie wymaga aby w takim menu były dane dokładne co do 1 w danej sekundzie Wtedy robisz sobie cache na n-minut i po sprawie. Zysk OGROMNY.

Takich sytuacji jest trochę, na ogół są to dane globalne serwisu, a nie spersonalizowane usera. Ale ciężko tak uogólniać bo co serwis to inne potrzeby i wymagania, chciałem tylko nakreślić pewien punkt widzenia, mam nadzieje, że widac o co mi chodzi.

Masz rację, w takim przypadku ustawia się cache na określony czas. Jednak, jak dobrze zauważyłeś, zazwyczaj nie oblicza się ilości plików w folderze lub wierszy w bazie, tylko stosuje dodatkowe pole, które zawiera informację o aktualnej ilości danych. Do tego należy dodać, iż sam licznik może być cache-owany co 5 min, a reszta strony co tydzień.

Tak, to może średni przykład ale oddał mniej więcej punkt widzenia. Sytuacji takich by się trochę znalazło, w każdym projekcie zdarza mi się z tego skorzystać raz czy dwa.

Nie, po stronie admina to ty mozesz wyczyscic cache klienta, a nie go generowac.
Prosta sytuacja: cache newsow. No i klient chce wyswietlic newsy, patrzy czy jest cache i jak jest to go odczytuje. Jak go nie ma to co? Czeka az admin go wygeneruje? A przeciez moze sie zdarzyc ze cache zniknie, chocby przez reczne wyrezanie go katalogu. A moze ma nie czekac az admin go wygeneruje tylko sam ma go generowac? No to wtedy duplikujessz w kliencie i w adminie te samą funkcjonalnosc.

Źle mnie zrozumiałeś. Chodzi mi o to, by nie generować cache w momencie, gdy użytkownik wchodzi na stronę, ponieważ co któreś wejście, będzie powodowało generowanie strony (bardzo wolno będzie się wchodziło). Cache można generować w cronie, który dla odpowiednich stron będzie generował statyczną zawartość.
A co w przypadku, jeśli ktoś wywali cache. Wówczas nie ma rady. Trzeba wczytać stronę dynamicznie.
Oczywiście rozwiązanie z cronem należy stosować z umiarem. Zbyt dużo uruchomionych skryptów publikujących treść też potrafi zabić wydajność.

edit
Oczywiście mogą zdarzyć się sytuacje, gdy generowanie z crona nic nie da, np różna ilość zmiennych przekazywana do skryptu. Wówczas pozostaje jedynie generowanie cache co jakiś czas podczas odwiedzin użytkownika.

prawdę mówiąc nie umiem sobie w tej chwili wyobrazić takiej sytuacji z tym cronem. nie przekonuje mnie to z tym userem (chyba, że masz dane które jednorazowo będą Ci się generowały >10s. ). Setki requestów na minutę samo załatwia sprawę tworzenia keszu. Być może jest gdzieś taka potrzeba.