(Amnemona nuotrauka)
Šiame įraše noriu papasakoti, kaip aš spartinau savo tinklaraštį ir kokių rezultatų sulaukiau.
Taigi vieną gražią dieną pasitikrinęs savo tinklaraščio krovimosi greitį pingdom tools ir pasižiūrėjęs wordpress sistemoje, kiek trunka SQL užklausos, nusprendžiau krovimosi rodiklius pagerinti. Įdiegiau WP Super Cache, WP Widget Cache ir PHP Speedy įskiepius. Tikslumo dėlėi, reikėtų paminėti, kad tinklaraštis tuo metu sukosi ant naujos 2.7 WordPress versijos.
WP Super Cache ir WP Widget Cache veikimo principas yra toks, kad nurodome kurios informacijos neatnaujinti, kai vartotojas savo naršyklėje paspaudžia „Refresh“ mygtuką. Šie įskiepiai, anot kūrėjų, iš resursams imlaus PHP padaro statinį HTML kodą, dėl ko vartotojo kompiuteryje jūsų tinklaraščio vaizdas pasirodo greičiau. Įdiegus šiuos du įskiepius ir suderinus visas nuostatas krovimosi greičio pokyčiai iš buvo pastebimi. Vietoje 7 sekundžių puslapis krovėsi „niekingas“ 4-5 s (pagal pingdom tools testus). Tačiau man to dar buvo negana. Edvino tinklaraštyje pamačiau, kad jis naudoja PHP Speedy. „O kuo aš prastesnis?!“
Įdiegęs šį įskiepį išlošiau tiek, kad 55-60 SQL užklausų vietoj 0,4 s buvo įvykdomos per 0,35 s.
Džiaugiausi puikiais rezultatais kol… vieną dieną norėjau atnaujinti kažkurį įskiepį, bet vietoj įprasto „Update sucsessful“, pamačiau „WP database error -10“ ar kažką panašaus. Pagūglinęs susiradau, kad čia nieko baisaus, tiesiog rankiniu būdu per FTP reikia pakeisti kelias index.php kodo eilutes. Pakeičiau – klaida ta pati. Mėginau suversti kaltę tinklaraščio šablonui, kadangi tuo pat metu kas antras-trečias „refreshas“ sugeneruodavo nekorektišką vaizdą ekrane. Mėginam keisti šabloną – vėl ta pati duomenų bazės klaida!
Kitas žingsnis – jungiuosi per phpMyAdmin ir atstatinėju duomenų bazę iš automatinės atsarginės kopijos. Duomenų bazė atsistato be klaidų, prarandu tik kelis komentarus ir vieną straipsnį. SVARBU: prieš atlikdamas šį žingsnį WordPress administravimo skydelyje pasidariau tinklaraščio kopiją per „Export->XML“.
Vėl mėginu atnaujinti įskiepį ir vėl ta pati klaida. Besimaldamas po talpinimo tiekėjo valdymo skydelį, kažkaip netyčia pastebėjau, kad išnaudota 101% laisvos vietos!!! Per failų tvarkyklę pasitikrinau – kas čia tiek vietos užima, kadangi prieš mėnesį tebuvo naudojami kuklūs 50-60 MB (grafiką talpinu išoriniuose šaltiniuose, taip tauposi vieta ir talpinimo srautas). Ko gero jau įtariate, kas gi tie niekadėjai, „suvalgę“ mano disko vietą. Teisingai – vadinamieji „kešai“ užėmė dešimt kartų daugiau, nei pats tinklaraščio turinys – įskiepiai padarė savo juodą darbą. Galbūt kitiems skaitytojams geriau susiklojo draugystė su visokiom tinklaraščio spartinimo priemonėm – parašykite komentaruose.
Iš šios istorijos dar sykį įsitikinau pirmojo inžinerijos dėsnio fundamentalumu („Jei viskas veikia – nieko neremontuok!!!“) ir dar sužinojau vieną naudingą dalyką – jei prieš ką nors spartindami ar keisdami tinklaraštyje pasidarėte XML turinio kopiją eksportuodami ją administravimo skydelyje – drąsiai galite atstatinėti straipsnius ir komentarus importuodami XML failą – jau esantys įrašai ir komentarai nebus nei perrašomi nei dubliuojami, importo mechanizmas esančius įrašus ignoruoja. O XML importas – lengviausias ir greičiausias būdas atstatyti turinį nelendant prie duomenų bazės.
Dainius yra svetainės Premaman ir jos tinklaraščio autorius ir administratorius. Jo papasakota istorija yra labai panaši į mano bandymus spartinti svetainės krovimą. Tinklaraščio įskiepius visada patartina bandyti atskirai, o tuos, kurie iš esmės koreguoja jo veikimą – dar ir labai atsargiai.
20 Comments
paveiklsiukas priverte nusisypsoti :D
Na reikėtų nepamiršti, kad pat cache’avimas tai yra procesas, kai atminties (tiek RAM, tiek diske) sąskaita yra taupomi skaičiavimo resursai.
Žinoma, gali pasidaryti automatinę užduoti, kuri kas kiek laiko pratrintų cache’ą, bet tikrai nemanau, kad lietuviškam tinklaraščiui gali reikėti cache’avimo – Lietuvoje tai tik didžiausių portalų problema…
WordPress kodo ir optimizavimo prasme (tinklaraščiui puslapyje – 60 SQL užklausų???) yra siaubingas produktas. Nors galimybės jo didelės ir administratoriaus sąsaja gražiai atrodo, knaisiotis po WordPress kodą yra košmaras.
knaisiotis po WordPress kodą yra košmaras – čia tik tiem, kas knaisiojasi, o aš, kaip neišmanantis, džiaugiuos normaliai (bent jau man taip atrodo) veikiančiu daiktu. Sutinku, kad WP nėra tobulas įrankis, tačiau su juo moku ir galiu padaryti veikiantį produktą per mane tenkinantį laiką. Kaip jau gyvenimas parodė – „geriausių“ daiktų _nėra_, vos tik praplėšęs akis iš ryto pradedi priiminėti kompromisus :)
Aišku, sekančiam tamstos komentare paminėtas atminties naudojimas aktualus, jei viename hostinge sukasi keli projektai. Kaži kaip su atmintim būna, jei keli tinklaraščiai „pakabinti ant vienos WP instaliacijos?
:-)
Pauliau, 60 uzklausu nera daug. Cia ne tokia koncepcija, jog iseitu issiversti su penkiom uzklausom.
Gzip kompresija geriausiai spartina puslapio krovimą, nes ~2/3 mažiau reik siųsti, naršyklė greičiau gauna html, css ir javascriptus, taigi iš kart viską sudėlioja, belieka laukti paveiksliukų ir flash, kurie visada vienodai krausis..
Taip pat ir šiandieniniams servams su Intel Xenon procais vienas juokas spausti Gzip. Apkrauna CPU pati kompresija, bet sumoje mažiau apkrautas servas, nes greičiau išsiunčia ir atsilaisvina resursai, ir žmogeliui mažiau siųsti. Galbūt tik telefonai gali sulėtėti, kurie turi silpną procą, kad išspaustų tuos puslapius, bet jei naršai 3G, tai vėl ant mažiau duomenų siuntimo visas pagreitėjimas išlošiamas. :)
Dar pridėsiu… WP atminties naudojimas yra 14 MB (šaltinis: http://webjawns.com/2009/09/wo.....-to-1-4mb/ ), o užmečiau akį į vieną projektą su keletu plugin’ų, tai atminties sunaudojimas yra ~25 MB.
Web aplikacijai tai yra tragiški rezultatai ir kalba jau turi eiti ne apie optimizaciją ar kešavimą, bet apie WP projektavimo ir programavimo defektus.
na taip, WP pakankamai rajus. Drupal’e žvilgterėjau: lyg 2MB
Bet va jame puslapį be 100 užklausų sugeneruot praktiškai neimanoma ;) Būna ir 500.
Dar būtų įdomu ir apie Joomla! ir Serendipity, jei kas esat čiupinėję. Kitokių CMS Lietuvoj, berods, nesu matęs.
šiaip nereikėtų labai jaudintis dėl užklausų skaičiaus. tai nuo papildomų funkcijų, modulių daug kas priklauso. Nemanau kad įmanoma padaryt patogią modulinę sistemą kuri generuotų mažai užklausų.
Tokia išplėčiamumo, funkcijų kaina.
Kaip sakoma, M$ nebemoka sukurti elementaraus tekstų redaktoriaus sverenčio mažiau nei 10 MB :) bet argi kam tai rūpi?
Kitaip sakant – nuolatinis „antklodės tampymas“ tarp „memory/cpu load“ ir „disk quota/traffic“. Dėl rūpėjimo – kol viskas veikia korektiškai – nerūpi, bet įdomu. Juk gyvenime – maža kas…
Mielas Pauliau,
visų pirma, daug maž standartinis wordpressas puslapio atidarymui daro apie devyniolika SQL užklausų.
visų antra, užklausa nėra lygu užklausai, ir wordpressinės užklausos nėra blogos (nuo 2.1, atspėkit kodėl). nepamirškit, kad ta pati programinė įranga sukasi ant wordpress.com, kur ant ganėtinai kuklių resursų nekuklūs skaičiai vartotojų sukabinti.
ko gero jūs susidėjot visus įmanomus ‘įskiepius’, ir kaip dori piliečiai viską ant platformos užvarot… bet taip, ko gero paprasčiau, negi ieškosi problemos tarpinėje tarp kėdės ir klaviatūros.
nežinau iš kokios operos jūs čia traukiat tuos visus skaičius, kas yra daug, kas mažai, bet akivaizdu, kad savo ištikimą auditoriją nieko nesuprasdami užverčiat belenkokiais skiedalais. na bet nieko, tokie gi dauguma blogų internete :)
o dėl knaisiojimosi po kodą, galėčiau ir gražesnių pavyzdžių rast.
tai, kad WP turi tokią techninę ekosistemą aplink save kalba už save.
na bet tiek to, ko gero jūs geriau žinot.
^^ ten ir Dainiui skirta :)
Aš tai nesu specialistas, todėl negaliu nieko tvirtinti, bet pakankamai pažįstu žmones, kad nustebčiau, jog ekspertai neturi laiko jokiam paaiškinimui, išskyrus užuominas apie kitų kvailumą…
Tam, kad kažką aiškint, reik geresnio žmonių požiūrio nei „… yra siaubingas produktas“ ;-)
Hmm. Nepastebėjau rašinyje tokio WordPress įvertinimo. Dainius pasakoja, kaip prisivirė košės padauginęs WP įskiepių. Tas pats buvo ir man, kai norėdamas turėti gražų straipsnių sąvadą, buvau įdiegęs įskiepį, kuris iš naujo rašydavo savo turinį į duomenų bazę po kiekvieno smulkiausio pasikeitimo tinklaraštyje. Nenuostabu, kad serveris pradėjo žagsėti ir pritrūko atminties. Išmečiau įskiepį ir viskas susitvarkė.
Ar šios istorijos, skirtos perspėti eksperimentuojančius kolegas, yra vertos tokio komentaro: „akivaizdu, kad savo ištikimą auditoriją nieko nesuprasdami užverčiat belenkokiais skiedalais. na bet nieko, tokie gi dauguma blogų internete“?
Net jei autoriai visiškai nugrybauja rašydami apie techninius dalykus, ar tai nereiškia, kad tie techniniai dalykai reikalauja platesnio specialistų paaiškinimo, jei jau paprasti vartotojai jais susidomėjo? Ar tik požiūrio: „nelįskite, durniai, kur neišmanote“?
Nuo kurio laiko entuziastų bendruomenė yra programų kūrėjų ir ekspertų priešas? Tai, beje, verta atskiros diskusijos. Pabandysiu sudėlioti mintis per savaitgalį…
aš truputuką apsižioplinau, ir komentuojantį Paulių supainiojau su straipsnio autoriumi.
Atsiprašau už tą vietą, kur kaltinu blogo autorius :)
per anksti paspaudžiau ‘siųsti’. šiaip pakankamai įdomus įvertinimas:
„Įdiegęs šį įskiepį išlošiau tiek, kad 55-60 SQL užklausų vietoj 0,4 s buvo įvykdomos per 0,35 s.“
Jeigu atkreiptumėte dėmesį į pati SQL užklausų vykdymo laiką, jis būtų gal net mažesnis už 20% viso scripto vykdymo laiko. WordPressas daug daugiau laiko praleidžia savo ‘filtruose’, nei SQL užklausose (ypač, po mano minėtos 2.1). nebent jūs tikrai matote atskirai profilyje iškeltą SQL užklausų kiekį.
Beje, tvarkingai veikiančio serverio SQL užklausos yra vykdomos per mažiau nei milisekundę, kažkur pusę milisekundės reikėtų pridėt, jeigu db serveris pasiekiamas per tinklą – tačiau kadangi kaitalioja operacinė sistema kontekstus, esant didesniam apkrovimui tiesiog laukiama truputį daugiau, nei reikėtų (ypač, jeigu yra daugiau negerų kaimynų, kurie mielai įsiterps į bet kada paduotą laisvo procesoriaus ‘langą’).
Jeigu tikrai norit pagreitinti savo blogo darbą, įsitikinkite ar PHP bytecode cache’as įjungtas ant serverio (APC, eAccelerator arba XCache) tai gali pagreitinti viską maždaug trigubai.
O iš tų visų greitinančių įskiepių – bet koks pagreitinimas yra pagrįstas labai paprastu principu – darbo nekartojimu. WordPressas turi labai nedaug darbų, kurių nekartojant kažkas labai taupytus, išskyrus visą puslapio generavimą – kas aišku sukelia tam tikrų šalutinių efektų (turinys gali neatsinaujint, kai tikimasi, kad atsinaujins).
Be to, kadangi standartinis blogas paprastai atidavinėja tris skirtingus puslapius per dieną (kuriuos tikrai verta kešuot), reikia labai sugebėt prigeneruot daug failų (t.y. vertėtų pravalyt senus failus ;-)
O su duomenų bazių klaidom nelabai galima pagelbėt, kai nepasakoma kokios jos :)
WP_Object_Cache su Memcache ir eAccelerator! =)
(tiesa, galima vien su eAcceleratorium gyvent, jei naudojamas jo key storage)
HDD file storage (WP-cache, WP-super-cache) daugeliu atveju nėra gera idėja.
Apie tai gal prabėgom užsiminsiu per (ne)konferenciją.
Matuoti blog’o krovimosi laiką su pingdom tools yra, švelniai tariant, netikslu. Dėl to, kad jis matuoja puslapio užsikrovimą lyg lankantis pirmą kartą. 5 sekundės tokiu atveju nėra kažkas baisaus. Daug svarbiau tinkamai cache’inti ir reusinti komponentus, kad sekantys puslapių atvertimai būtų kiek įmanoma spartesni.
Tinkamai suoptimizavus blog’ą, eilinis requestas turėtų būti aptarnaujamas per ~0,2s (puslapio generavimo laikas iš serverio pusės) su ~15 querių.
Jei gerai cache’inami komponentai, HTTP trafficą sudarys tik html kodas, nauji (kituose puslapiuose nenaudoti) paveikslėliai ir statistikos/reklamos scriptai.
Geriausios priemonės matavimams – Firebug su YSlow ir HTTPFox (Firefox plugin’ai).
Savaitę nežiūrėjau ir štai kiek atsiliepimų! Ačiū, vienastoks, kad truputį apgynei. Nors nelabai čia kas ir puolė :)
Aš iš esmės nieko nesakiau apie WP blogumą, nes geriau tikrai nepadaryčiau. Patogumo jis man irgi patogus, čia gal veikia tas vidutinio amžiaus žmonių sustabarėjimas, kad su kuria sistema išmokau dirbti, tai su ta patogiausiai viskas ir gaunasi. Aišku, al ir su drupal sugebėčiau pasimokęs paleisti tinklaraštį per 10-15 minučių, bet tai čia laiką reik paskirti :) O pats straipsnis, kaip ir vienastoks rašė, buvo apie „prisidirbimą“, o ne apie platformos blogumą. Dėl tarpinės tarp monitoriaus ir kėdės – nesiginčiju, bet čia gali būti tik vienas vienintelis trūkumas – rankos kreivos, todėl ir gaunasi taip, kaip rašė Chionsas – panaudojau netinkamą metodą.
Šiaip visuose „tobulinimuose“, stengiuosi naudoti kuo mažiau įskiepių, nes priklausomumas nuo įskiepių mažina platformos mobilumą ir spartą.
Tiek minčių šiam kartui.