Performanse velikih PHP-MySQL projekata

[bluesman]

1. Zaboravi smarty za to

Ostalo sledi kad budem imao vremena

[Ilija Studen]

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

[dinke]

Originalno napisao Ilija Studen

premature optimization is the root of all evil.

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.

[kalkulus]

Originalno napisao Ilija Studen

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

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

[Petar Marić]

Originalno napisao kalkulus

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

[kalkulus]

Originalno napisao BlueIce

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

istina
dakle, zanemaricemo moj losh izbor reci i nastaviti dalje

[Petar Marić]

Nema ozbiljne optimizacije bez profiling alata.

[Ilija Studen]

Originalno napisao kalkulus

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

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

[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"

[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?