medutis
Birželis 30, 2006

PHP optimizavimas

Kaip žinia, nėra tikra programavimo kalba, t.y. skriptai yra interpretuojami vykdymo metu, priešingai nei daugelis kompiliuojamų programavimo kalbų. Yra įvairių, pvz. kad ir kompanijos Zend siūlomų įrankių, kurie leidžia šiek tiek pagerinti šį reikalą, pvz. optimizuoti ir užkoduoti skriptus į bytecode, tačiau tai vistiek nėra taip greita kaip mašininis kodas.
Dėlko reikia gerinti performancą? Pagrindinės priežastys, iš kurių išplaukia visos kitos:
- taupyti pinigus,
- laimingi klientai.

Be abejo, yra daug būdų kaip kuo daugiau išspausti iš turimų resursų.
Vienas iš jų - daugiau “hardware”. Galingesni serveriai, dual-procesoriai ir kt. ir pan. be abejo aiškiai leis pajusti pagerėjimą, jei tik dabartinė įranga su tuo nesusitvarko. Labai dideliems portalams, protingai sujungtos serverių sistemos leis ryškiai pagerint visą veikimą, na bet čia jau sistemų administratorių darbas. Hardwariškai galima pagerint ir specifines sritis, pvz. SSL užkodavimai su programine įranga atima daug jėgų iš procesoriaus, todėl galima įdiegti specialią plokštę, kuri tai atliks netrugdydama procesoriaus. Tokios kortos aišku kainuoja tūkstančiais, bet jei suksim nerealų internetinį biznį, tai negi neverta investuoti?
Na o dabar pats kodas. Visiškai aišku, kad jei programos kodas bus greičiau ir efektyviau vykdomas, galėsite daugiau nuveikti su ta pačia hardware įranga.
C bibliotekos - kaip žinia, buvo sukurtas naudojant C kalbą. Nepaisant to, kad vis greitėja, C programos veikia vistiek greičiau. Jei sukursite kažkokius sudėtingesnius algoritmus su C kalba ir jas vykdysite iš - kodas veiks sparčiau. tai galima atlikti sukuriant atskirus extension’us. Tokie moduliai gali būti išoriniai, užkraunami skripto vykdymo metu, arba vidiniai - įkompiliuojami tiesiai į vidurius. Aišku, naudodami savo extensionus prarasite dalį to paprastumo, patogumo ir portabilumo, kurį suteikia , tačiau specifiniais atvejais tai suteikia tik privalumus.
Kodo pagreitinimas. yra interpretuojama programavimo kalba. Tai reiškia, kad kaskart vykdant skriptą, Zend variklis jį nuskaitys, išparsins, įkompiliuos į atmintį ir tada įvykdys. Kadangi skriptai paprastai nesikeičia bent jau nuo vienos užklausos iki kitos, parsinimas ir kompiliavimas kartojami kaskart ir yra laiko ir resursų švaistymas. Kodo greitinimo produktai šiandien leidžia to atsisakyti palaikant sukompiliuotus skriptus atmintyje. Zend kompanija šiam reikalui turi paruošusi rimtų produktų, kurie kainuoja ir nemažus pinigus, tačiau egzistuoja ir nemokami kodo acceleratoriai.
Turinio kešavimas. Įsivaizduokime, kad draugas paskambina Jums ir paprašo sužinoti kokia šios dienos “Vakaro žinių” antraštė. Jūs nueinate iki artimiausio spaudos kiosko, grįžtate namo ir pranešate draugui apie antraštę. Jums paskambina antras draugas ir paprašo to paties. Ar vėl eisite iki kiosko? Na, turbūt nebent tokiu atveju, jei pirmo apsilankymo metu įsimylėjote kioskininkę. Jei taip nėra, Jūs pakankamai protingas, kad suprastumėt jog pateikta užklausa yra analogiška, ir tikėtina, kad atsiminsite antraštę. Deja, HTTP serveris nėra toks protingas, ir turbūt labai dažnai laksto į spaudos kioską (tarkim, duomenų bazės serverį). Turinio kešavimo idėja paprasta: serveris dirba sunkiai kad sugeneruotų rezultatą į užklausą. Šiuos duomenis jis tada laiko po ranka, ir kai gauna tokią pačią užklausą, tiesiog panaudoja prieš tai sugeneruotus duomenis. Tai be abejo ir sumažina web serverio apkrovimą, tačiau efektas daug aiškiau matysis duomenų bazės serveryje, kuris gaus labai mažai užklausų. Viskas atrodo paprasta, tačiau smulkmenose iškyla ir problemų. Pavyzdžiui, kaip atpažinti ar užklausa yra panaši užklausa, ar skiriasi (ar mano draugas prašo šios dienos “Vakaro žinių” antraštės, o gal vakarykštės, o gal nori “Ekstra žinių” arba jis gyvena Anglijoj ir skaito Didžiosios Britanijos “Vakaro žinias”). Taip pat reikia nuspręsti, kaip valdyti kešavimą, kada ištrinti senus duomenis ir kaip tinkamai valdyti resursus (pvz. negaliu atsiminti visų laikraščių antraščių, tai kurią yra geriausia pamiršti).
Failų lygio kešavimas. Jei puslapis yra matomas daugeliui vartotojų toks pats, galima užkešuoti jį visą į vieną failą. Įsivaizduokime, tarkim delfi.lt titulinį puslapį. Nauji straipsniai tarkim įrašomi kas 15 minučių. Galime vykdyti kešuotų duomenų laikymą tarkim 5 minučių intervalu. Dabar, jei tarkim į puslapį per 5 minutes ateis 1000 lankytojų, tik vienas skriptas ir vienas kreipimasis į duomenų bazę bus įvykdytas vietoj 1000. Neskaitant šito vieno laimingojo, likusiems duomenys bus patiekiami tiesiog iš kešo, tarsi tai būtų statiniai HTML failai. Turint laiko limitą šiems kešuotiems failams, nauja antraštė blogiausiu atveju atsiras po 4min 59sek. Be to, galima ir šitą nepatogumą lengvai apeiti, atsiradus tarkim labai svarbiam straipsniui apie Brazausko atsistadynimą, kurį būtina paviešinti akimirksniu. Pavyzdžiui, turint kokį nors patogų skriptą, kuris vieno mygtuko paspaudimu “rankiniu būdu” panaikina kešuotus rezultatus ar ir pats juos sugeneruoja iš naujo. Kartais tenka apsvarstyti ir įvairių užklausų variacijas, neskaitant unikalaus URL adreso. Skirstant kešuotus duomenis verta apsvarstyti ir GET parametrų, globalių http kintamųjų, sausainukų (”cookies”) įtraukimą į kešavimo sūkurį. Pavyzdžiui, reikia užkešuoti skirtingus titulinius puslapius, priklausomai nuo vartotojo geografinės vietos ir pan.
Dalinis kešavimas. Failų kešavimo privalumai aiškus, tačiau dažnai tam tikri puslapio laukai yra priklausomi nuo unikalaus vartotojo. Pavadinkim tai “welcome, UserName” problema. Šiuo atveju visas puslapis yra vienodas visiems vartotojams, tačiau mes įterpiame asmeninę žinutę puslapio viršuje. Nebegalime kešuoti viso puslapio, nebent mums nesvarbu, kad Petras, Jonas ir Juozas matys užrašą “welcome, Marytė”, tai yra pirmojo asmens, kuris davė užklausą pirmasis, vardą. Sprendimas yra dalinis puslapių kešavimas. Mes visdar galime kešuoti didžiąją dalį puslapio, kuri, tikėtina ir naudoja didžiąją dalį užklausų į duomenų bazės serverį. Tai nusprendžiama jau API lygyje, tai yra skripte, kuriam nurodytas specialus segmentas, kuris turi būti pakeistas perduotu parametru ar priklauso nuo skripto pobūdžio.
Duomenų bazės tarpinis kešavimas. Šis būdas leidžia atskirti kodą nuo duomenų bazės. Vietoj to, turime skriptą, kuris vykdomas periodiškai ir ištraukęs duomenis iš duomenų bazės serverio, išsaugo juos į HTML gabalus failuose, kurie po to įterpiami kai skriptas formuoja rezultatus. Sprendimas šiek tiek sudėtingas ar ne itin patogus, tačiau kai kuriais atvejais gali būti naudingas.
Duomenų bazės . Programuotojai nesivadintų programuotojais, jei didžiausio dėmesio neskirtų būtent kodo optimizavimui. Deja, net greičiausiai veikiantis algoritmas neatstos laiko, kurį sugaiš prastai parašyta SQL užklausa į duomenų bazės serverį, kurios netinkamai suformuotos ar nenaudoja reikalingų indeksų. Jei skiriate laiko savo kodo gerinimui, skirkite jo ir išsiaiškinti, kaip išgauti geriausia, ką gali duoti duomenų bazės serveris. Kaip ir duomenų kešavimo atveju, nedidelės pastangos duos labai gerų rezultatų, kai paoptimizuosite sąveiką su duomenų baze.
Gzip kompresija. Kartais nebūtinai reiškia kodo taisymą ar duomenų nuskaitymą iš serverio ar failų. Optimizuoti galime ir duomenų perdavimo galiniam vartotojui sąskaita. Didelių duomenų perdavimas taip pat kaip ir viso serverio pralaidumo išnaudojimas gali nepatikti vartotojui. Nors čia atrodo jau negalime daug ką pakeisti, tačiau duomenų suspaudimas čia gali pagelbėti. Didžioji dalis šiuolaikinių naršyklių gali gauti suspaustus duomenis ir sugeba pačios juos automatiškai išarchyvuoti. Naudoti duomenų spaudimą paprasta: tereikia įjungti “zlib.output_compression = on” .ini nustatymuose. Reikia pažymėti, kad duomenų suspaudimas suteikia darbo procesoriui kiekvienos užklausos metu. Tai vėlgi galime apeiti, apjungę kompresiją su kešavimu. Tiesiog kešuojame jau suspaustus duomenis.
Kompiuterių tinklo struktūros gerinimas, nors ir nėra programuotojo reikalas, tačiau taip pat galimas puslapio veikimo gerinimo būdas. Kai kurie kompiuterių tinklų įrenginiai gali atlikti jau paminėtus optimizavimo metodus hardware lygmenyje ir turi daugybę kitų galimybių.
Ką pasirinkti? Be abejo, kiekvieno atvejis yra unikalus, todėl reikia atkreipti dėmesį, kokių iškyla problemų būtent Jūsų puslapiuose. Taipogi, atsirinkite, kokia įranga ar kokie metodai yra Jums prieinami, ir ką jais galite pasiekti. Kai atsakysite į šiuos klausimus, optimizuoti bus lengviau.
Optimizavimą palengvina ir vis gelbsti mūsų naudojama programinė įranga. Vis naujesnė išleidžiama web serverio ar versija reiškia, kad ji turi kažkokių pataisymų, susijusių ir su optimizacija, todėl visada verta įsidiegti stable naujausias versijas. 5 versija su Zend varikliuko antra versija siūlo naujas objektinio programavimo galimybes, kurios ne tik palengvina patį programavimą, bet ir pagreitina skriptų veikimą. Duomenų bazių serveriai tai pat tobulėja - MySQL 5 versija turi daugybę galimybių, kurių iki šiol nebuvo.
būtinas ne tik ir ne tik dėl pinigų taupymo ir vartotojų patenkinimo. Pajutę optimizavimo svarbą tapsite geresniu programuotoju, taip pat ir pagerinsite įvaizdį web technologijų kovoje.

Panašūs straipsniai


“PHP optimizavimas” komentarų: 5

  1. Pawka

    Truputį pasikabinėsiu prie žodžių :-)

    “… Kaip žinia, PHP nėra tikra programavimo kalba, t.y. PHP skriptai yra interpretuojami vykdymo metu…”

    Programavimo kalbos nėra skirstomos į tikras ir netikras. Viską kas turi sąlygos sakinius ir ciklus, galime vadinti programavimo kalbomis. O tada jau galima jas skirstyti į interpretuojamas, kompiliuojamas ir t.t.

    Kalbant apie projektų veikimo spartą, visų pirma rekomenduočiau pasižiūrėti į patį kodą. Neprotingas kodas gali prailginti veikimo laiką 10 ir daugiau kartų. Žinoma, jei projektas nėra didelis, tai nebus akivaizdžiai pastebima. Pamenu, kai žinomas KTU dėstytojas J. Blonskis pareiškė man nesuprantamą teiginį, jog šiais laikais taupyti resursų nėra reikalo, nes kompiuteriai labai galingi. Manau, bet kokiu atveju kodas turi būti švarus ir optimalus ir geras programuotojas turi to siekti.

  2. imbusy

    “Pamenu, kai žinomas KTU dėstytojas J. Blonskis pareiškė man nesuprantamą teiginį, jog šiais laikais taupyti resursų nėra reikalo, nes kompiuteriai labai galingi.” - Jis tikriausiai neturėjo omeny tokių kritinių atvejų. Galima netaupyti vartotojo resursų, o ne serverio.

  3. Pawka

    Jis tikrai nekalbėjo apie serverį, tačiau bet kokiu atveju jo teiginys mano atžvilgiu yra klaidingas. Pažiūrėk į naujausią MS produktą Windows Vista. Jo instaliacija užima berods 7 gigabaitus. Ar tai protinga? :-)

  4. HEADSHOT

    kai naujuosiu pc dabar daznai sutinkamas 200gb hdd tai paprastas vartotojas ju taip ar taip neisnaudoja ir gali skirti 7gb windowsam bet pvz. man tai butu vos neketvirtadalis kompo hdd 0_o…

  5. Pawka

    Tai vat, kad automatiškai atsiranda poreikis pirkti galingesnę sistemą. Pvz galim palygint Windows ir Linux operacinių sistemų naujausias versijas. Aš sėkmingai naudoju naujausią Ubuntu versiją ant savo 450 Mhz laptopo. O apie naujausią Windows versiją net negalėčiau pagalvoti su tokia sistema, nekalbant apie tai, kad ji užimtų ~25% mano HDD. Manau ir su XP kiltų problemų. Akivaizdžiai matosi gamintojų požiūris.

Rašyti komentarą

Jūs privalote prisijungti jeigu norite rašyti komentarą.