Performanse velikih PHP-MySQL projekata
 

Evo jos jednog ne-PRO pitanja :)

Pravis PHP + MySQL sajt
i zahtev je da sajt mora izgurati veliki broj clanova
(npr preko 10K clanova, preko 400 online).

Kojih se pravila pridrzavate pri programiranju?
Sta nikako ne sme da se radi, a sta je 'dobra praksa'?
Vasa iskustva u vezi performansi kod velikih projekata.

Hvala!
ps. ne znam smarty :) a i malo je vremena da ga ucim :)

1. Zaboravi smarty za to :)

Ostalo sledi kad budem imao vremena :)

Takva skripta spada u medium traffic tip skripti i tu optimizacija za brzinu ne bi trebala da bude preterano bitna stvar pod uslovom da se držiš par prostih parvila. Uostalom, pogledaj ovu temu, tu ima dosta korisnih saveta.

PS: Obavezno enkodiraj skriptu. Time ćeš dobiti i do 200% ubrzanje izvršavanja, a da ne takneš kod. Naravno, dosta parametara utiče na ukupno vreme izvršavanja, ali enkodiranje daje ubedljivo najbolje rezultate kad je čist PHP u pitanju. Za dalje obavezno koristi keširanje, optimizuj upite (učitavaj samo ono što ti treba i kad ti treba) itd.

Takođe, ne zaboravi na jednu stvar: premature optimization is the root of all evil. Ovo isto valja imati na umu ;)

Ovo je inace citat u podnaslovu poglavlja naslovljenog sa "How do I optimize my code" u PHP Anthology Vol II (inace u pitanju su reci Donald E. Knuth-a).

E sad, posto mi je Ilija "ukrao" omiljeni citat, mogu samo da ti kazem da je pre svega bitan dizajn. Moja omiljena uzrecica je da su brzi programeri skuplji od brzih procesora. Dakle, bitno je da aplikacija ima dobar dizajn koji ce ti omoguciti lake izmene na aplikaciji, nadogradnju, code reuse i sl. pa tek onda eventualno popravljati perfomanse.

shta tacno podrazumevash pod ovim, prvo naterati neshto da radi pa ga onda optimizovati ili neshto drugo?

Mislim da ako nešto moraš naterati da radi, onda programiraš na potpuno pogrešan način :p

istina :)
dakle, zanemaricemo moj losh izbor reci i nastaviti dalje

Nema ozbiljne optimizacije bez profiling alata.

Ne bukvalno. Ako se samo trudiš da čisto nateraš nešto da radi najverovatnije ćeš skrpiti nešto što niko posle tebe neće moći raspetljati.

Optimizacija dolazi tek na kasnije, kad je aplikacija već u potpunosti funkcionalna. Naravno, platformu biraš u skladu sa specifikacijom: nećeš za nešto gde je prioritet brzinu izabrati Ruby ili Javu (u domenu web aplikacija), već PHP, Perl... Dok kodiraš ti već manje više optimizuješ kod za brzinu ("dobre programerske navike"), ali to ti definitivno nije cilj. Cilj ti je da napraviš funkcionalnu aplikaciju koja radi posao. Tek kad je sve gotovo uzimaju se test podaci, profiler alati i slične "igračkice" i počinješ da juriš uska grla i optimizuješ za brzinu.

Generalno postoje dve brzine: brzina izvršavanja i brzina razvoja, ali to je već neka druga priča...

PS: Ovo je manje više sa praktične strane, a sada će Petar da počne da teoretiše :P

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?

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.

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

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...

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 :D

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...

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.

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 :)

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.

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..

@smarty speed: prosto govoreci, sto je veci fajl koji includujes, vise vremena je potrebno da se zavrsi odredjena operacija. naravno, akcelerator tu priskace u pomoc. smarty je razbijen u nekoliko ne bas malih fajlova, pa samo ucitavanje svaki put oduzima odredjeno vreme, a isto tako, izvrsice bar nekoliko filesystem operacija pre nego sto dodje do zakljucka da template ne mora ponovo da se parsira.

Bojane, smarty u svakom slučaju ima izvestan overhead zbog učitavanja fajlova, registrovanja klasa, instanciranja istih i pozivanja njihovih metoda. Da li gorespomenuti overhead predstavlja značajni gubitak u perfomansama odlučuješ uporednim benchmarcima.
Znači, opet test-cases i profiler u šake ;)

Takođe mislim da za zaista velike stvari PHP nije najbolje rešenje, jer tada dolaze do izražaja greške/nedostaci u dizajnu istog (kao jezika i platforme).

Your friendly neighborhood theorist ;)