Performanse velikih PHP-MySQL projekata

[boccio]

Originalno napisao McKracken

Naravno, najbitnije je da planiras scalability. Mnogi su pukli jer im je sve radilo lepo, ali kad je trebalo da se skalira pocinje "veselo popodne"

Sto dovodi do zanimljivog pitanja...

Kako radite load&stress testing aplikacije? Na koji nacin simulirati, recimo, 1.000 konkurentnih zahteva? Nailazio sam na neke alate, tipa http://www.loadtestingtool.com/, ali jel to to, ili se koristi i nesto iz domace kuhinje?

[dinke]

Svojevremeno sam za SiteBuilder (www.cafeid.com) imao zahtev da mora da podrzi 10 000 korisnika. Da bi smo simulirali ponasanje sistema sa 10k korisnika napravio sam script koji kreira 10k accounta kako bi se na odgovarajuci nacin opteretio sistem. Kolega je pravio script koji simulira simultane konekcije (u Perlu) pa smo pratili load sistema. Inace (malo se samoreklamiram SiteBuilder je preveden i na srpski (koristi se gettext) pa mozete i da pogledate kako izgleda ako nekoga interesuje.

[Petar Marić]

@Ilija: E baš neću, tebi u inat

[ivanhoe]

eh, da ne budu svi saveti teoretske prirode (a i nov sam na forumu pa moram da se pravim pametan ) evo par saveta koji su meni mnogo znacili:

1. optimizacija koda je realno potrebna u svega 10-tak % koda, pri cemu su ti naravno petlje glavni kandidati...sav ostali trud je cisto trosenje developer sati... zato profilisi blokove koda sa microtime() i vidi sta trosi najvise vremena.. takodje proceni koje ce skripte da nose najveci load pa se samo oko njih trudi, one koje se pozivaju jednom u 3 dana su ti potpuno nebitne u ovom scenariju... oko optimizacije php koda ne treba biti previse paranoican jer realno najvece vreme ti odlazi na ucitavanje i kompajliranje skripte, a tu nema pomoci (osim Ilijinog saveta sa pocetka threada)

2. Konekcija na bazu je nasjporiji deo rada sa bazom, zato koristi samo jednu bazu i perzistentne konekcije(samo pazi da tako svako apache dete dobije po jednu stalnu konekciju koju nikad ne prekida, sto moze da bude problematicno ako je broj konekcija limitiran ili ima previse apache procesa). Takodje procitaj vrlo pazljivo savete za optimizaciju iz mysql helpa, odlicni su. Ovo se u praxi pre svega odnosi na upotrebu tabela sa fixnim duzinama polja kad god je moguce, i na pravilno indexiranje tabela. Tabele koje se najvise koriste (recimo ako sessione cuvas u bazi) obavezno pravi bez varchar i text polja, znaci strogo tipovi fixne duzine, jer tako radi znatno brze. Kod indexiranja treba obratiti paznju na indexe po vise polja i kako ih koristi mysql, tako moze dosta da se dobije na brzini. Takodje treba paziti da svaki index usporava insertovanje u bazu, znaci tamo gde se puno insertuje gledaj da ti treba malo indexa. I jos stvar koja mi nikad nije bila jasna, ali je provereno tacna, treba voditi racuna o redosledu uslova iza where, jer nije svejedno kojim su redosledom dati zavisno vec od indexa koji su na raspolaganju. Mysql ima foru da pogledas koje indexe baza koristi za koji upit pa uvek proveri da li radi onako kako si ti zamislio.

3. par stvari oko mysql-a koje mislim da ne pisu u helpu: mysql se ne snalazi najbolje sa velikim tabelama, znaci deli tabele na manje kad god to ima smisla, bice ti mnogo brze. Takodje ne ume bas najbolje da radi sa joinovima, pogotovo kad su velike tabele u pitanju, cesto je mnogo brze uraditi 2 odovojena upita pa ih spojiti iz php-a (treba izmeriti vreme pa videti naravno).

eto ovo je sve sto mi momentalno pade na pamet, a i mislim da je sasvim dovoljno za vrlo pristojan rad.. mada u principu vazi savet koji je vec ponovljen vise puta: Pisi kod lak za odrzavanje, pa tek zatim optimizuj i to posmatrajuci sajt u realnom radu, pa ako snimis da ima gusenja popravljaj samo te skripte koje prave problem...

[Petar Marić]

Hm, zaista ne mogu da prihvatim microtime kao relevantan benchmark - postoji jako dobar razlog zašto se ljudi upozoravaju da ne pišu svoje f-je već da koriste biblioteke koje dolaze uz samu platformu.
Pošto OS-ovi koje tradicionalno koristimo nisu RTOS (Real Time OS) ne možemo znati kad će se i koliko će se procesor preključiti na drugi proces, tako da imamo veoma nepouzdana očitavanja sa izrazitom relativnom greškom.
Sa veoma kratkim vremenima relativna greška raste i sve postaje veoma veselo za profiling...

I could go on and on, al opet će me Ilija prozvati da teoretišem

[ivanhoe]

pa skroz si u pravu, ali jel postoji neki bolji nacin od microtime() za ovo u php-u?


nije savrseno,ali to resis tako sto ne radis profilisanje samo jednom(nego jedno 100-njak puta sa dovoljnim sleepom izmedju ponavljanja), i naravno ne testiras na production serveru nego na kucnom boxu na kome si pogasio sve ostale zahtevne procese...

statisticki greska bi trebalo da je slucajna promenjiva uniformne raspodele u vremenu, pa onda ne utice na relativne odnose kod poredjenja, to jest ako je dobijena srednja vrednost iz npr. 100 merenja kod jednog pristupa 3 puta brza od srednje vrednosti nekog drugog resenja, onda je to prilicno siguran orijentir, jer bi trebalo da je srednja vrednost greske ista kod oba slucaja...

[dinke]

Uzgred, kad smo vec kod profiling-a da pomenem dva korisna alata:

XDebug - Debugger
http://www.xdebug.org/

Advanced PHP Debugger
http://pecl.php.net/apd

Vec postoje linkovi u onoj top temi sa resursima, ali rekoh da postujem i ovde. Igrao sam se sa XDebug-om svojevremeno i mogu da kazem da je fin alatic za profiling (korisniji od time f-je svakako) . Tu je naravno i Zend studio, ali on nije besplatan.

[Petar Marić]

Statistika se baš i ne da jednostavno primeniti u tom slučaju... Preključivanje na drugi proces je stohastično, te iskreno rečeno mislim da bismo pre mogli primeniti ponešto iz teorije haosa, nego iz konvencionalne matematike.
Najsigurniji način bi bio da se napravi virtuelna mašina i da se sva merenja rade u odnosu na nju - razlog zašto je u Javi 5 profiling znatno lakši. Na našu žalost IIRC Zend engine nije baš najoštriji nož u fioci (jelda zvuči glupo na srpskom ) što se tiče izolovanja virtuelne mašine i samog profilisanja, tako da je korišćenje workarounds nezaobilazno.

No, opet ja teoretišem

[dinke]

Originalno napisao Petar Marić

No, opet ja teoretišem

A gore si rekao da neces, cccc

@ivanhoe
Ovi saveti za mysql optimizaciju su odlicni. To koliko mysql brze radi sa poljima fiksne duzine vidis tek kad tabele narastu na par desetina Gbyte-a. To sam naucio pre par godina na svojoj kozi kada sam morao da optimizujem neke tabele sa vise miliona usera. Stvari tipa username, ip adresa i sl za koje znas da ne idu vise od 15 karaktera, obavezno stavljati kao char a ne varchar.

[Bojan Zivanovic]

Vidim da bluesman spominje da nema leba od Smarty-ja za vece projekte..
Koliko je velik taj udar sto se performansi tice, i da li bi se moglo zaobici (cache, a smarty kompajlira samo jednom template...)?
I da li bi brzi bio neki template engine koji direkt koristi PHP, kao sto je Savant?
Mislim, znam da bi bio brzi, al pitanje je da li bi i on radio posao..