Mam pytanie.

Bawie sie silniikiem gry Gamer-Fusion i mam pytanie (nie chodzi tylko o ten silnik, ogolnie), co mozna cachowac w grze tekstowej via www?

Ogólnie to wszystko, głównie zapytania...

Wyobraź sobie , że masz nagle na stronie 20 tyś użytkowników i wszyscy oni pobierają dane z bazy... A tak to jeden pobierze raz na np. 5 minut ...

@up a co w przypadku jak większość danych musi być dynamicznie pobieranych? Np jakaś mapa, a po tej mapie poruszają się inni gracze i żeby każdy się widział, to po 5 minutach dopiero się zobaczą bo odświeży się cache?

Nie tyle co cache, co optymalizacja i konkretny sprzęt. Cache w przypadku dynamicznych danych nijak nie spełni swojej roli.

Ja u siebie do danych dynamicznych (ale nie takich co zmieniaja sie co sekunde ale np raz co minute a raz co 10 minut) stosuje cache które jest dostępne za pomoca jakiegos ID i podając to ID mozna je rowniez wykasowac. I Dla bardziej popularnych fragmentow dynamicznych strony w modelach ktore grzebią w tych danych usuwam zawsze cache jezeli istnieje (te cache ktore sie zdeaktualizowaly), jesli robie commit do bazy danych.

Ale trzeba sie przy tym troche opisac, w przypadku ogolnym jest to raczej niewykonalne.

Najfajniej jest cachować kawałki strony i z tych kawałków sklejac całą stronę, nie cachując elementów silnie dynamicznych.
Np dla strony z mocno rozbudowanym nagłówkiem, zawierajacym menu generowane na podstawie bazy danych, zastapienie nagłówka i stopki elementami cachowanymi i regenrowanymi w razie potrzeby skrocilo czas ladowania kazdej podstrony o prawie połowę.

widze ze Crozin czyta ten temat, więc powiem Tak, tam przydały się aktywne widoki ktore same sprawdzaly czy cache jest swieze i regenerowały sie w razie potrzeby a jak nie to wczytywaly sie z cache, a z punktu widzenia kontrolerów czy byly cachowane czy nie wygladalo to w dosc czytelny sposob: $view->render() praktycznie zadnych zmian w poroownaniu do wersji bez cachowania kawałków.

wiem ze jest esi ale cache w klasach widokow jest mniej klopotliwe, nie wymaga robienia routingu specjalnie dla cachowanych fragmentów. moze varnish troche szybciej dziala ale mimo wszystko silnik PHP rowniez znacznie szybciej skleja pliki niz generuje od nowa HTML.

Ja przychylam sie raczej do cachowania gotowych zrenderowanych kawałków stron niż zapytań - wychodzi w zasadzie na to samo, a wydajnosc jest jeszcze lepsza. Bo jesli ze scachowanego zapytania wyrenderujemy troche htmla 2 razy to 2 razy wyjdzie nam to samo, nie ma sensu, lepiej zapisac do pliku/apc gotowy html.

co ciekawe, zauwazylem ze cachowanie gotowego htmla w plikach dziala szybciej (ok 20%) niz cachowanie w APC. Nie umiem tego wyjasnic, moze to wynika z marnego dysku na moim lapie.

Masz racje tez doszedlem do takiego wniosku.
Jesli moge robi cache calego komponentu a jak nie to tylko jego czesci czyli tak zwane regiony.Jednak juz w usuwanie cache regionow przy jakims updatem sie nie bawilem(choc to jest 1 linijka kodu) bo tak czy siak cache sie sam usuwa co np 10min

Napisałem o co mi chodziło z tymi danymi dynamicznymi, czyli powiedzmy aktualizowanych co 1sekundę. Nie wiem czy jest wtedy sens cachowania takich danych.

Napisałem ten temat ze względu na te dane dynamiczne

W sumie myślę jak by_ikar.

A zcachuje tylko jakies rankingi itd

Dzięki za odpowiedzi.

Tak, cachowanie rankingów, czy innych podstron których dane nie odświeżają się co sekundę jest nawet jak najbardziej wskazane. W przypadku szybko zmieniających się danych, pozostaje optymalizacja samych zapytań, optymalizacja bazy danych pod konkretne zapytania, oraz dołożenie ramu i trzymanie jeżeli to jest możliwe, całej bazy w pamięci ram. Lub nawet wydzielenie bazy na osobną maszynę. To wszystko zależy od ruchu jaki przewidujesz. Im większy, tym zapotrzebowanie się zwiększy..

Powiedzmy, że będzie zalogowanych 100/200 osób.

Jakiej maszyny potrzebuje, żeby utrzymać grę pisaną struktularnie w której skrypty i zapytania są zoptymalizowane?

Wydaje mi się że średniej klasy dedyk powinien dać sobie spokojnie radę. Aczkolwiek, mogę się mylić, bo nie tworzyłem nigdy takich projektów, ale jeżeli to by były w większej mierze same updaty (zmiana lokalizacji gracza) + jednocześnie selecty (pobranie informacji o pozostałych graczach, w danym obszarze), to aż tak wymagające to nie powinno być, więc wydaje mi się że w serwerze za 100-200zł miesięcznie powinieneś spokojnie bez większych obaw móc działać. Oferta 24g: http://www.kimsufi.pl/ jest IMO bardzo kusząca, 24gb ram spokojnie ci pozwoli na umieszczenie większej części bazy, lub nawet całości w pamięci ram, i wydzielenie kawałka pamięci ram dla samej strony (ramdisk) co by przyspieszyć samą stronę jeszcze, nie szczególnie obciążając dysk. No i też zależy od serwera http jakiego użyjesz, polecam nginx, lub lighttpd