Optymalizacja skryptu pod kilka tysięcy userów, Jakie rozwiązania przyśpieszające? Opcje

[wojto]

Witam,
Jestem obecnie w trakcie tworzenia bardzo dużego serwisu i chciałbym się dowiedzieć od was jakie sztuczki stosujecie by skrócić czas wykonywania skryptów.
Serwis ma być czymś podobnym do http://date.com oraz http://sympatia.onet.pl , ma mieć kilka wersji językowych, więc będzie prawie tak popularny jak w/w.
Serwisy te mają bardzo dużą odwiedzalność, dla przykładu w obecnej chwili na tych stronach znajduje się ponad 5 tysięcy użytkowników online!!!
Ponadto zarejestrowanych jest tam pewnie z kilkadziesiąt tysięcy, jeśli nie kilkaset tysięcy userów.
Dziennie wysyłanych jest kilka tysięcy prywatnych wiadomości.

Jakie rozwiązania zastosować, by ten serwis działał w miarę szybko.

Serwis będzie działał na bazie mysql.
Jak narazie, to jedynym rozwiazaniam jakie wykorzystałem jest cachowanie niektórych zapytań, ale wiadomo, że nie wszystkie zapytania moge zcachować.

Zrezygnowalem z plikow językowych typu lang_polish.php, lang_english.php itp. gdzie w zawartości była tablica $lang['user'] = 'użytkownik'; itp. na rzecz folderów, gdzie w folderze np. en/ będą wszystkie pliki, ale z treścią w języku angielskim, w folderze fr/ będą wszystkie pliki, ale po francusku. Myśle, że przyśpieszy to troche działanie skryptów, gdyż nie trzeba będzie pobierać plikow językowych oraz kod skryptów będzie prostszy, wadą jest natomiast to, że przy dowolnej zmianie kodu, należy go zmienić we wszystkich folderach.

Z góry dziękuje za wszelkie uwagi i propozycje odnośnie usprawnienia takiego serwisu.
Pozdrawiam, wojto

[scanner]

Nie żebym się czepiał, ale...

2. Oracle, albo inna baza z konkretnym wsparciem ($M SQL)- tutaj bardzo ważne będzie to ze jak ci padnie baza to 1. nie będziesz szukał w manualach a tel i juz sprawa zalatwiona 2. bedziesz mial sporo dodatkowych narzedzi ktore pozwalaja monitorowac stan bazy i wiele innych rzeczy.

Jeśli za wzór stawiasz tu MS'a, to wybacz - ja wysiadam. Prędzej znajdę coś w MSDN'ie niż "jednym telefonem". Wiem bo przeżyłem niejeden hotline po wsparcie techniczne.

Podobnie ma sie sprawa z ORACLE'em - bardziej ich interesują papierki niz wsparcie - wiem, bo firma ma licencjonowanego O9i więc kontakty z O też pewne mam (miałem).

Ale to tylko dygresja.

Tak jak mówił DeyV: pakiety szablonowe umożliwiają prekompilacje i cache'owanie wyników - to primo. np. Strona "o osobie" - a taka na pewno będzie - może być prekompilowana jako static i tylko odświeżamy cache (force-update) przy modyfikacji danych w niej zawartych.
To samo dot. plików językowych - można powyższe rozbudować, jeśli dynamicznie będziemy generować dynamicznie również ścieżkę do cache'u, np:

/home/local/user/www/cache/$_SESSION['lang']/....

Jedyna wada: nadmiarowość danych na dysku - najprostsze równanie to liczba_zarejestrowanych * liczba_jezyków * średnia objetość strony = X

Oczywiście zgadzam się co do rozbicia serwera na maszyny specjalizowane - ale w podanym przypadku wystarczy WWW + MySQL - najlepiej stojące obok siebie, spięte gigabitowym kabelkiem.
Oczywiście mówimy tutaj o maszynach wyposażonych w bardzo szybką pamięć i dyski SCSI.

Mam w pracy jeden taki serwerek na Oracle'a; Pentium IV 2,4 GHz, 768 MB RAM (niestety tylko 333 Single-Channel), 3x 33,6 GB SCSI360 HotSwap Raid 0+1 (AFAIR). Jeden dysk to system, drugi i trzeci spięte w mirroring - jakie to piękne uczucie móc wyciągnąć jeden dysk z RAIDa bez wyłączania czegokolwiek czy informowania użytkowników.

A tak wracając na ziemię - EXPLAIN do SQL'a oraz profiling (jak na przykład xDebug). Na przykładzie tego drugiego, możemy z DeyVem Wam powiedzieć, ze analizując jeden dość skomplikowany mechanizm, z wyników na poziomie 4 sekundy (5500 linii trace) zeszliśmy do 0,8 sekundy (1300 linii trace) - a to wszystko podczas 4 godzinnej burzy mózgów przy jednym monitorze. I to należałoby podkreślić. Nawet jeśli projektowanie, debugowanie i optymalizacja miałaby ci zająć 2x tyle czasu, ile planujesz w tej chwili -zysk jest przeogromny.

Przy okazji: weź pod uwagę już na poziomie projektowania szablonów, że możesz w przyszłości wprowadzić skórki - czyli od razu dołóż drugą zmienną do ścieżki cache - zaraz po lub przed językiem.

W planach mam pewien skórkowany wielojęzykowy serwis okołounijny - i już się cieszę, że będzie on stał na serwerze, gdzie poza kontem roota istnieć będą tylko trzy inne konta dla developerów (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)