Zbog hrpe posla skoro sam zaboravio na dors/cluc 2006. Ionako nisam mogao na prva dva dana predavanja, ali nisam namjeravao propustiti i radionicu Rasmusa Lerdorfa Building Rich Web applications with PHP 5. Za one koji možda ne znaju, Rasmus je otac PHP-a, a trenutno je Yahoo djelatnik zadužen za infrastrukturu i arhitekturu, PHP, Apache, web2.0 i web servise. Za detaljnije upoznavanje s njegovim likom i djelom poslušajte IT Conversation interview u kojem Rasmus govori o tome kako je nastao PHP i kuda ide.

20.4. je Rasmus održao predavanje Web 2.0 and PHP 5, a isto predavanje održao je i dan prije u Varaždinu. Iako niste bili na predavanju zavirite malo u tu prezentaciju, ima zanimljivih primjera.

Jučer je na redu bila radionica čiju prezentaciju možete pogledati ovdje: Architecture and Performance. Prva i druga prezentacija imaju nekoliko zajedničkih stranica, izgleda da je Rasmus dan prije ukratko najavio sadržaj radionice.

Najprije nas je upoznao s MVC (Model, View, Controler) arhitekturom čijoj je promociji, za web okruženja, najviše pridonio RubyOnRails, a sada je slijede (i kopiraju) mnogi. Iznio je dvojbu: page ili front kontroler?! Većina okruženja za razvoj odabrala je front kontroler dok je Rasums za page kontroler. Specifičnost front kontrolera je u tome da svi zahtjevi u web aplikaciji prolaze kroz njega, dok kod page kontrolera pojedini dijelovi web aplikacije imaju svoje ulaze (stranice, datoteke). RL smatra da web aplikacije ne treba raditi na isti način kao i desktop aplikacije. Web se može isjeckati, napraviti dio po dio, ne postoji uvjet stroge kompaktnosti.

Zatim je pokazao primjer jednostavne aplikacije koja je trebala ilustrirati ono o čemu govori. Za sebe je sam rekao da je paranoidni optimizator, tako da je tu i tamo to ilustrirao ponekim detaljem. Npr. umjesto okidanja funkcije koja vraća vrijeme on koristi (jasno tamo gdje mu apsolutno točno vrijeme nije nužno) $_SERVER["REQUEST_TIME"]. Na taj način je uštedio jedan sistemski poziv. Kod shared hostinga i stranica s relativno malom posjećenošću, takva optimizacija nema previše smisla, ali kod njih u Yahoo-u svaki je dijelić ušteđenog vremena dragocjen.

RL ne voli framework-e. U većini slučajeva oni donose više nego što vam treba, imate hrpu datoteka koje se učitavaju, kod koji baš i nije prilagođen vašim potrebama. Pristaje na framework iz kojeg može izdvojiti dio koji mu je potreban, a ostalo može zanemariti. Kao primjer je naveo Yahoo JavaScript UI biblioteku iz koje mu je trebala animacija pa je samo nju uzeo. Naveo je kako svaki PHP programer, koji tijekom vremena radi na sličnim zadacima, može razviti svoje okruženje koje će biti efikasnije i prilagođenije njegovom načinu rada. Kad treba birati između urednosti koda i performansi, RL uvijek bira ovo drugo. Ovo što spominjem RL je ispričao u razgovoru pod pauzom. RL je inače jako pristupačna i jednostavna osoba koja jasno iznosi svoje stavove pri čemu ne ulazi u sukob sa sugovornikom.

U prvom dijelu predavanja nisam otkrio ništa što već nisam znao, ali zato je drugi dio bio pravo malo otkriće. U prezentaciji ta priča počinje od osme slike: How to Get Rich. RL je na praktičnom primjeru pokazao kako se može optimizirati aplikacija. Prvo pokretanje dalo nam je 17 obrađenih zahtjeva u sekundi da bi to uz par jednostavnih zahvata naraslo na 1120 zahtjeva u sekundi. Neki developeri smatraju da preveliko optimiziranje nema smisla jer je hardveraj jefitiniji nego njihovo vrijeme. To je kod web aplikacija samo djelomično točno. Obratite pažnju na broj 284 koji označava broj milisekundi potrebnih za obradu jednog zahtjeva. Vi možete povećati broj servera i na taj način povećati broj obrađenih zahtjeva, ali latencija će ostati ista. Pojedini posjetitelj će i dalje relativno dugo čekati na odgovor. Cilj optimizacije je smanjenje te latencije.

I onda je RL pokazao callgrind, a kada je shvatio da je većini slušateljstva to nešto novo, rekao je kako je to što ćemo vidjeti najkorisnija stvar u sklopu predavanja. Callgrind je i meni bio nova stvar, ali ubrzo sam shvatio kako može biti jako, jako koristan.

RL je ubrzao aplikaciju tako što je isključio ssl enkodiranje u Postgresu (čemu enkoding ako je sve na jednom računalu), podesio stalnu vezu na bazu, koristio je i optimizirao APC (npr. require_once nema smisla ako se koristi APC), objasnio važnost definiranja punog puta do datoteke koju uključujete (include) u kod, pokazao za što se i kako koristi apc_store, rekao kako je PHP kod bolje držati u manje velikih nego više malih datoteka. RL je ubrzao aplikaciju i zamjenom Postgresa MySQL bazom. Osvrnuo se na 'neprekidna poboljšanja u brzini' koja sa svakom inačicom spominje Postres tim. RL je rekao da je istina da je vidljiv stalni napredak, ali zbog toga što ima dovoljno mjesta za napredak. Spreman je kritizirati MySQL zbog njegovih manjkavosti, ali je naglasio njegovu najveću značajku: brzinu.

Na kraju je latencija smanjena na ispod 4ms (naspram početnih 284). Po RL-u bolje je da server obradi brže manji broj zahtjeva, nego da više zahtjeva obrađuje sporije tj. duže. Ukoliko ste uspjeli smanjiti latenciju onda čitavu stvar možete ubrzati (tj. pojačati) dodatnim serverima.

Sva ta priča oko optimizacije na pomaže previše nama koji vrte aplikacije na shared hostingu, ali oni koji imaju kontrolu nad serverom mogu postići značajna ubrzanja. Ne znam da li je netko od blog.hr ekipe bio prisutan, možda bi nešto od spomenutog pomoglo da njihov server lakše diše.

Rasmus je izuzetno zanimljiv predavač, zanimljiv je, priča izuzetno razgovjetno (za razliku od nekih predavača koje sam slušao prošle godine u Opatiji) tako da se slušateljstvo može koncentrirati na ono što priča. Ocjena 5/5. Organizatori, pozovite ga opet.

dorscluc2006