Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Optymalizacja skryptu pod kilka tysięcy userów
Forum PHP.pl > Inne > Hydepark
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
SongoQ
Wazna rzecza sa optymalne zapytania, co z tego ze bedziesz mial mechanizmy php wykonane bardzo dobrze a bazka bedzie zwracala rekordy kilka sekund.
Mysle ze na to powinienes zwrocic uwage. Wazna sa tez testy, przetestuj dla takiej ilosci rekordow jakie zakładasz ze nie wystapią nigdy.
kicaj
Cytat(wojto @ 2005-03-07 15:13:53)
...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!!!...

...ale nie w jednej chwili (momencie, sekundzie, etc), tylko np. w ciagu ostatnich 5-10min
DeyV
1. przy pewnej wielkości serwisu stawia się dla niego dedykowaną maszynę.
A nawet gdy tak nie jest - zazwyczaj podstawowym ograniczeniem jest przepustowość łączy - a nie obciążenie procesora. Szczególnie gdy baza danych jest na osobnej maszynie.

2. Tworzenie równoległych wersj serwisu dla różnych wersji językowych wydaje mi się zupełną pomyłką.
Lepiej by było już napisać jakiś mechanizm, który "wkompilowywałby" do szablonu odpowiednie tłumaczenia, i tak przygotowane pliki zapisywałby na dysku w osobnych katalogach. (jest to całkiem łatwe do wykonania przy wuększości systemów szablonów)

3. Tak jak to już sotało napisane - ważniejsze jest optymalizowanie struktury bazy, niż skryptów php. Te, szczególnie przy zainstalowanym jakimś akceleratorze php, zazwyczaj nie obciązają zbyt mocno maszyny.
lol
Cytat(DeyV @ 2005-03-07 15:16:16)
1. przy pewnej wielkości serwisu stawia się dla niego dedykowaną maszynę.
A nawet gdy tak nie jest - zazwyczaj podstawowym ograniczeniem jest przepustowość łączy - a nie obciążenie procesora. Szczególnie gdy baza danych jest na osobnej maszynie.
.

Mozna tez kupic dedyka zagranica. Ale przy tych dedykach,, m.in. juz szybkosc lacza nie ma znaczenia, ale niestety wlasnie szybkosci procesora i wielkosc ramu ma znaczenie.
hwao
Cytat(wojto @ 2005-03-07 15:13:53)
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ć.

Mi sie wydaje ze MySQL moze padac i bedziesz mial cos jak problemy epuls' z baza danych(chociarz na epulsie pewnie jest mniej userow to troblemy beda :-) ).

Sa inne stabilnijsze bazy danych.

Co do samego kodu to najlepiej testowac komponenty skladowe i sprawdzac jakie rozwiazanie jest najszybsze (np unsetowac nie potrzebne juz zmienne)
wojto
@Kicaj: wiem, ze jest to w ciagu kilku minut, to przyjmijmy ze jest tysiac w danej sekundzie (uprzedze przyszle wypowiedzi: wiem, ze ten tysiac nie wykonuje akurat w tej jednej sekundzie zapytan smile.gif)

@DeyV: czyli chodzi ci o stosowanie tych pliow jezykowych (a'la phpBB), czy cos innego?
Dodam jeszcze, ze nie ma narazie zadnego systemu szablonow, bo szablon bedzie tylko jeden, oraz tylko jeden programista, wiec szablony mijaja sie z celem.

@hwao: niestety, ale nie mam wyboru zmiany bazy danych, klient taka ma i na takiej musi byc.
Możesz powiedzieć coś więcej o problemach tego serwisu?
SongoQ
@wojto
Cytat
bo szablon bedzie tylko jeden, oraz tylko jeden programista, wiec szablony mijaja sie z celem.


To ze bedziesz sam pisal to wcale nie wyklucza nie stosowania szblonow. Wydaje mi sie ze w php wazna rzecza jest odzielenie prezentacji o logiki.

@hwao Z tym to roznie bywa, wazne aby optymalne zapytania byly. Odnosnie ilosci zadan w danech chwili to jakos nie udalo mi sie znalezc info na ten temat. Wazna rolę w duzych bazach odgrywa sprzet.

Jesli mozesz to napisz o problemie epuls, strasznie jestem ciekaw.
sztosz
Zgadzam się ze bardzo ważna jest optymailzacja zapytań. Pomocne jest tu EXPLAIN , po prostu tłumaczy jak wykonane bedzie zapytanie i można łatwo wyśledzic co w tym zapytaniu zmienic.
patrycjusz
pokolei...
1. maszyna - dedykowana maszyna to nie tylko - dedykowana maszyna pod kazda z uslug - to tak - czyli dzielimy uslugi na mail, http, i bazke, i kazda z tych uslug ma osobna maszyne, nie musza byc jakies mocarne (za wyjatkiem pod baze tam min. 2GB RAM), ale wazne jest to ze bedzie to podzielone na uslugi i zawsze jak padnie ktoras z nich to duzo latwiej jest przywrocic to do poprzedniego stanu (pada sql to tylko odpalasz backupowa maszyne z sqlem) , a takze obciazenie jest odpowiednio rozkladane, co nie znaczy ze nie mozna wymyslisc jeszcze czegos lepszego, bo mozna i np. do wszystkiego dolozyc proksiaka.
2. Oracle, albo inna bazka z konkretnym wsparciem ($M SQL)- tutaj bardzo wazne bedzie to ze jak ci padnie baza to 1. nie bedziesz szukal w manualach a tel i juz sprawa zalatwiona 2. bedziesz mial sporo dodatkowych narzedzi ktore pozwalaja monitorowac stan bazy i wiele innych rzeczy. Podsumowując, przy takim obciążeniu można sobie oczywiście pozwolić na MySQL jak najbardziej wszystko najprawdopobniej będzie można sklepać w oparciu o niego, ale późniejsze rozwijanie tego i serwis to tragedia nawet dla specjalistów, wobraź sobie że coś ci pada i na wszystkich forach ci mówią - nie znmy odpowiedzi a manual siedzi cicho?questionmark.gif,
Podsumowując,
tak naprawde wszystko zalezy od tego jakich uptimow oczekujecie, jak 99,5% w miesiącu to nawet nie mao czym mówić przy takim obciążeniu dzielimy usługi plus dodajemy różne wynalazki (proxy), a jako bazkę używamy pewnych sprawdzonych produktów z wsparciem prosto od producenta.

pzdr
scanner
Nie żebym się czepiał, ale...
Cytat(patrycjusz @ 2005-03-08 13:57:41)
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:
Cytat
/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 smile.gif
patrycjusz
Cytat(scanner @ 2005-03-08 15:11:48)
Nie żebym się czepiał, ale...
Cytat(patrycjusz @ 2005-03-08 13:57:41)
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.

hmm.. mam zupełnie inne doświadczenia,
wiesz wydaje mi się że zależy to raczej od firmy która $M lub Oracle obsługuje, ale dotychczas nie spotkałem się z żadnym problemem a moi znajomi którzy stawiają naprawdę spore aplikacje korzystają tylko z tego, no cóż jak w każdym przypadku zdarzają się odstępstwa od reguły smile.gif
scanner
Akurat z tymi dwoma firmami mam średniopozytywne doświadczenia.
Co nie zmienia faktu, że sam Oracle jako Oracle jest potęgą. Ale z drugiej strony - mniejsze tankietki odpowiednio użyte mogą częstokroć wskórać więcej niż duża superforteca.

Ale to już temat na inny wątek, nieprawdaż?

Wiadome jest jedno: Ze względów ekonomicznych, pierwsze wersje tematycznego engine'u powstaną na MySQL'u lub PostgreSQL'u (lub np. Interbase/Firebird, którego właśnie poznaję) - a w tej sytuacji kłania się wydajny DB Abstraction Layer. I to właśnie jest jednym z problemów do rozwiązania na początku.
Synaps
Panowie nie przesadzajmy z tym Oracle i MS SQL'em. Moim zdaniem do ww projektu MySQL chociaż baardzo przereklamowany winksmiley.jpg wystarczy. Wystarczy pod warunkiem ,że pisząc tą aplikacje zadbamy o napisanie dobrego cache'a który odciąży baze i nie będzie problemów.

OT: Jeszcze w sprawie samego Oracle'a, po co wam support ta baza jest samo wystarczalna ( przynajmniej od ver. 9 ) cool.gif
patrycjusz
@scanner: niom dokładnie temat na inny wątek, ale moim zdaniem baaardzo duży temacik i wart obgadania, ciekaw jestem waszych praktyk z dużymi dostawcami smile.gif

Co do samej bazy to powiem może taki przykład z którym mam (miałem) styczność,
baza - MySQL, waga - kilka GB, obciążenie - przy kiepskich dniach kilka tysięcy wywołań (najmniej w statach widziałem coś ponad 3 tys) - zakładam że na jedno wywołanie przypadają średnio 4 odwołania SQL, średnio złożone (po jednym joinie, z where po intach). I teraz przy ciężkich dniach (pon,wt,piatek) ilość wywołań przekracza dziennie 50 tyś, oczywiście serwer dedykowany (lecz bez dzielenia usług).
Kod - php - w całości strukturalnie, bez szablonów itd.
W pierwszej fazie jak to zobaczyłem .... mój Boże ale syf.... smile.gif
Poproszono nas o audyt to troche polecieliśmy po tych kilku serwisach które korzystały z tej jednej bazki, i w pierwszej fazie nie zuważyłem aby się to cieło, chodziło w miarę płynnie, bez wyraźnych zakrztuszeń nawet przy szczytowym obciążeniu.... ALE rozwój tego.... odpadł....
Nie było nawet o czym mówić, jakość kodu mimo iż wysoka (facet od SQL znał się na rzeczy, a pozostałe elementy nie budziły zastrzeżeń -> odpowiednie funkcje php na swoim miejscu itd) to cokolwiek tam wpleść to ... khmm.. smile.gif
Robiliśmy kolejny ich serwis w którym miały być tylko wyciągane dane z bazki, i z tym sobie po kilku dniach zamotania poradziliśmy (w bazie póki nie posprzątano na nasze wyraźne życzenie -> było blisko 500 tabel -> po sprzątnięciu -ponad 150 smile.gif
pamiętam wyraz rzseattle jak to zobaczył heheh smile.gif
kto by pomyślał że taka firma a tam taki burdel hehe smile.gif
no ale reasumując.... w php+mysql można skodować baaardzo wiele, ale problem zaczyna się wtedy kiedy to bardzo wiele zaczyna być dużym systemem, z dużym obciążeniem, i sporym narzutem transakcyjności, wtedy bez czegoś takiego jak punkty kontrolne w Oracle i wiele innych elementów które zapewnia ta baza jak coś nie daj Boże pierd... to może być problem smile.gif
Więc jeżeli bierzesz się za to i pozostają Ci narzędzia free, to php + postgres lub inna podobna bazka, i kodować to oczywiście baaardzo mocno z głową smile.gif
NoiseMc
Trochę odświeżę temat.

Panowie a jak wygląda sprawa jeżeli chodzi o klastry. Wiem jak jeżeli chodzi o bazy danych - kilka maszyn, baza rozproszona, ale jak to wygląda jeżeli chodzi o serwery www, nie jestem pewien ale chyba Fotka.pl stoi na kilku serwerach.
Kinool
@NoiseMc tzn moze byc tak ze fotki sa magazynowane na innej maszynie, baza danych na innej a calos oskryptowania na jeszcze innej smile.gif
NoiseMc
Myślałem, że jest kilka lub kilkanaście serwerów ustawionych w "klastry" (właśnie nie znam dokładnie pojęcia klaster), serwery są między sobą synchronizowane co jakiś czas (coś na zasadzie replikacji bazy danych - jeżeli nie mylę pojęć) i w zależności od np. zajętości serwera lub lokalizacji użytkownika serwis serwowany jest z innej maszyny. Chciałbym wiedzieć jak to jest realizowane, co decyduje o tym z której lokalizacji dane są serwowane (router blink.gif ). Czy ktoś ma doświadczenie w tej kwestii ? Wiem, że np. do J2EE są wzorce projektowe dotyczące tego zagadnienia.
Sh4dow
Panowie jesli chodzi o te bazki to nie wydaje mi sie zeby mysql przy takim serwisie az tak bardzo odchodzil z wydajnoscia. Osobiscie pracuje przy serwisie ktorego baza siega juz ponad 1 Gb na mysqlu i chodzi bardzo fajnie. Kwestia odpowiedniego skonfigurowania bazki oraz poprawnej konstrukcji przy jej projektowaniu.
Przy wielkich obciazeniach baza spokojnie sobie radzi przy statach w okolicach sredniej ilosci zapytan 150 na minute. To prawda ze serwer jest dedykowany dla serwisu i nie jest strupem z piwnicy, ale przekonalismy sie w firmie ze przy tak duzych bazach postgres chodzil wolniej i brakowalo mu pamieci.
Tak wiem ze mozna oracle mssql i inne smieszne rzeczy, ale dla mnie rodzi sie pytanie po co. Najpierw niech serwis zacznie dzialac, monitoruj jego wydajnosc itd a pozniej rob kolejne kroki i tyle
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-2025 Invision Power Services, Inc.