Buvo planuose pereiti ant v9, bet ....
Peržiūrėti temą
PHP-Fusion Mods :: PHP-Fusion modifikacijų forumas :: Modifikacijų, įskiepių diegimas
 v7 Optimizacijos
|
|
| Elektronix |
parašyta 2010-04-28 14:44
|
Pradinukas Reputacija: 0 Pranešimai: 27 Įstojo: 2008-05-10 |
Gal kas papasakotumet bent keleta be 1 ir 5 punktu ,kaip reik padaryt ? http://www.*a?*/t...vimas,s174 ?is straipsnis tiems, kurie turi didelius projektus paremtus Php-Fusion sistema. Tai yra, kai ra? skaiius lentelse pradeda vir?yti 100k. Taigi, bedarydamas updeitus ?iam tinklapiui, vienas j yra pabandyti j ka?kiek optimizuoti. Kadangi ?itas didelis dramblys pasidar labai ltas kaip pradjo valgyti lenteles su 500k ra?. Taigi, pirmiausia, ap?velgsiu jau prie? metus, por ar dar seniau padaryt sistemos atnaujinim optimizacijos at?vilgiu. PA?ENGUSIEMS VARTOTOJAMS (advanced-users) 1.Taigi, pirmasis ?ingsnis bt - "spauskime sraut" (maincore.php): ob_start(); eiluts keitimas ob_start(ob_gzhandler); ?is ?ingsnis mums leid?ia persisti tinklapio sraut vartotojui suspaustu pavidalu. Tai gana ?enkliai takoja krovimo laik. Beje, domumo dlei yra ir kit srauto spaudimo bd, ne tik "ob_gzhandler", taiau ?is yra, matyt, populiariausias. 2.Antrasis etapas - "sudkime indeksus" Kad suprastumte, kada ir kur tai daryti, nra sunku. Tiesiog per tinklapio failus pasileiskite kok TC ar Notepad++ kuris jums i?mest daugiausiai(pagal svarb, nuo svarbiausio): 1."WHERE" (laukeliai pagal kurios ie?kome - SVARBIAUSIAS ir esminis 2 etapo faktorius) 2."group_by" (kai grupuojame ra?us naudodami kelias lenteles) 3."ON" (kai norime susieti lenteles) 4."AS" + "count()", "sum()" ir t.t. (u?klausos mysql dalys, kai sumuojame, skaiiuojame ar pan. laukelio ra?us dalyje "SELECT") 5."SELECT" COL (?is ?ingsnis aktualus tik vykd?ius 3 etap ir pakeistus u?klausas i? "SELECT *" "SELECT COL(s)" dalyse naudojamus laukelius. Taigi, prisijung prie PhpMyAdmin ar kokio kito duom. bazi valdymo pulto, tiesiog sudkime "INDEX" tipo raktus(KEY's) daugiausiai naudojamiems laukeliams. Kaip pavyzd tarkim, galime paimti "online_ip" i? lentels "{prefix}_online", bei "user_ip" i? lentels "{prefix}_users". Jeigu esame sidieg SIP ar kokias kitas su IP suri?tas saugumo sistemas, tikrai da?nai naudosime "WHERE" u?klaus ?iems laukeliams. Tad sudti indeksus ?iems lenteli laukeliams yra pravartu. Toliau i? aktuali bt galima paminti: "thread_id" lentelje "posts" (kadangi da?nai grupuojame postus pagal tem) "user_name" lentelje "users" (da?nai ie?kome vartotojo vardo) ir daugel kit. Esm paprasta - sudkite kuo daugiau pamintus punktus patenkani indeks. ?inoma persistengti neverta, nes vieno indekso teikiama nauda su kiekvienu nauju lentels indeksu ma?ja. Kritiniais variantais toks indekso padjimas tinkamoje vietoje gali suma?inti tinklapio krovos laik nuo 15-16 sekund?i, iki vos 1-2 sekund?i. 3.Treio etapo esm - "NESIRINKIME nenaudojam laukeli": ?io punkto esm manau labai puikiai suprantama - kalbu apie u?klausos, duom. baz, dal "SELECT (laukeli sra?as)". Jeigu Js tinklapis pilnas SELECT * tipo u?klaus - vadinasi esate tikrai neoptimizavs tinklapio ir bereikalingai ?vaistote serverio resursus. Pagal idj, "SELECT laukelis1,laukelis2 " ir t.t. turt bti tik tie lentels laukeliai, kuriuos i?kviesite ?emiau seksianioje funkcijos implementacijoje, ar bet kokiame kitame informacijos i? duom. bazs i?transliavime tinklapio HTML kod vartotojui. Tinkamai pasinaudojus ?iuo punktu, tinklapio krovos laik galite suma?inti iki 10 kart. Na bet jeigu ka?kiek ribojimo jau buvo, indeksai irgi dalinai sudti buvo, tai galite tiktis 2-4 kartus greitesnio krovimo. 4.Ketvirtas etapas - "Nesaugokime ISTORIJOS - archyvuokime j" ?i funkcija labai aktuali tiems kas stebi lankytoj sraut - i? koki tinklapi lankytojai ateina, kiek per?ir padaro, ar dar kada lanksi pastaruoju metu ir t.t. Prad?ioje galbt nieko ir nejausime, taiau tinklapiui esant populiaresniam po pusmeio ar met, ms log' lentels prads daryti griozdi?kos, i? nejuiomis nepajusite kaip tinklapio krovos laikas prads ilgti. To esm, ilgos paie?kos didels apimties lentelse. Taip ia duoda naudos btin laukeli SELECT dalyje apibr?imas, indeks sudjimas ir t.t., bet 'net ir geriausias vairuotojas nevarys ma?inos u? ma?inos plot siauresn gara?'. Todl, geriausia tokiu atveju i?eiti - failo pabaigoje pasira?yti papildom u?klaus, kuri, tarkim Js lentelei vir?ijus 30k (30.000) ra? dyd, automati?kai perkelt juos archyvine lentel, pvz. "{prefix}_users_visited_pages_ARCHIVE", tokiu atveju archyviniai duomenys visuomet bus i?saugoti, taiau tikrai netakos tinklapio darbo, be to darant duom. bazs kopijas, nereiks sistis kaskart(u?teks tik vien - pradin kart) mil?ini?ko dyd?io byl - U?ARCHYVUOT lenteli turinys tampa statiniu ir nekeiiamu. Taiau papildomo failo pagalba, galite suteikti administratoriui kartas nuo karto pasi?irti t lentel - u?klausos bus ilgos, bet jis tai ?inos. 5.Penktas etapas - "Optimizuokime lenteles": ?io etapo prasm paprasta - visados nepamir?kime pasinaudoti "phpmyadmin" suteikiama funkcija "optimize" duom. bazs lentelms. Da?nai atsitinka, kad dl ry?io truki, ar serverio trikd?i ar ?iaip koki problem sivelia klaid ir atsiranda duomen perteklius duom. bazs lentelje, kartais perteklius gali bt ir keliasde?imt megabait, jeigu lentels apimtis didel ir ji buvo ilg laik neotimizuota. Optimizuodami lentel, i?sprend?iame ?ias 'mini' problemas ir kartu laimime tinklapio krovos laiko. :) 6.?e?tas etapas - "Naudokime LIMIT X funcija": Btinai rekomenduoju naudoti LIMIT funkcija kur tik manoma. T.y. verta aukoti tiksum vardan u?klausos laiko. Tipinis pavyzdys - u?klausos sutapim kiekis atliekant paie?k tarp post. Vis pirma jeigu turime tarkim 500k ra? post lentel, paie?kos rezultatams rekomenduojama gra?inti ne daugiau kaip 100 ra? per 5-iuose - 10-tyje puslapi. Tai yra gyvendinta Php-Fusion v7 versijoje, taiau ia pamir?ama smulkmena - kaip viena eilut yra pateikiama informacij apie bendr sutapim skaii - sakoma "rasta 95521 sutapimai vietoje 100 maksimaliai galim". TAI KLAIDINGAS SPRENDIMAS[/u]. Verta paaukoti tikslum ir gra?inti atsakym pvz. "rasta vir? 500 sutapim vietoje 100 maksimali leistin". Vartotojui informacijos pilnai u?tenks, taiau mes galsime i?lo?ti sistemos resurs bema? de?imteriopai dj ms rezultat skaiiavimo u?klausos pabaig kod "[b]LIMIT 501". 7.Septintas etapas - "Protingai pasirinkime ORDER BY reik?mes": ?io etapo esm - nedkite ORDER BY r?iavimo sql u?klausose, pagal dideli lenteli ne pirminius(PRIMARY KEY/ UNIQUE INDEX) atributus. T.y. jeigu pvz. jungiame u?klaus i? keli lenteli, kur vienos lentels dydis yra 10 tkst. atribut, o kitos lentels dydis - 500 tkst. atribut, ir abi lentels turi datos laukel, pagal kur Js norite r?iuoti savo rezultatus, tai esant galimybei verta aukoti dal tikslumo i?lo?iant u?klausos laik da?nai net ir de?imteriopai ar ?imteriopai. Php-Fusion sistemos konkretus pavyzdys bt paie?kos sistema: ORDER BY p.post_datestamp Verta keisti : ORDER BY t.thread_detestamp Nors ir prarandame tikslumo, esant 10k tem ir 500k prane?im, mes i?lo?iame u?klausos laiko ?imteriopai. 8.A?tuntas etapas - "Rinkims ma?esni lenteli laukelius": Logika paprasta - tarkime ie?kome jungdami tris lenteles ".DB_POSTS." p, ".DB_THREADS." t ir ir ".DB_FORUMS." f. Pirmosios dydis yra 500 tkst. eilui, antrosios - vos 10 tkst, treiosios - vos 20 ra?. Todl SELECT dalyje pakeit fraz: "SELECT p.forum_id, p.thread_id, p.post_id, ..." Fraze: "SELECT f.forum_id, t.thread_id, p.post_id, ..." Galime i?lo?ti iki 5-10 proc. sistemos resurs. Priklausomai nuo eilui lentelse kiekybinio santykio. PATYRUSIEMS VARTOTOJAMS (expert-users) 9.Devintas etapas - "Sekime u?klaus "Load time". ? dalyk gyvendinti gana paprasta - pasiimkite bet kuri i? microtime() funkcij reazijuojani mikro-laiko laikmai skript(funkcij) ir tiesiog saugokite: --> Bendr tinklapio krovos laik ("START" prad?ioje po pirmj eilui maincore.php faile [PRIE? visas mysql u?klausas ir bet kokias skaiiavimo funkcijas], "END" pabaiga theme.php footer dalies pabaigoje [PO vis mysql u?klaus ir bet koki skaiiavimo funkcij]) --> Kiekvieno modulio krovimo laik (startinis laikas fiksuojamas i?kart po "opentable()", pabaigos laikas - eilut prie? closetable() funkcij) --> Kiekvienos u?klausos krovos laikas (fiksuojama prie? ir i?kart PO u?klausos) Taip i?sived ekran visus krovos laikus, galsite nesunkiai matyti kuriose btent vietose susidaro "tinklapio butelio kakliukai" arba "silpnieji ta?kai". Nesunkiai analizuodami gaut informacij galime nusprsti k daryti su ltomis u?klausomis(pirmiausia, ?inoma jas paband kiek manoma optimizuoti): a)Retinti j i?kvietim (rodysime j kas kelint kart) b)Apskritai atsisakyti ?i u?klaus ar funkcij c)Ie?koti tobulesns sistemos ar modifikacijos, kuri atlikt t pat darb su kur kas geriau paruo?ta duomen struktra ir saugojimu d)Saugoti funkcijos rezultat, ir kviesti j reiau. e)Keisti atsakymu tip (jeigu kalbame apie dbcount(), tai keiiame "DESC LIMIT 1"); f)Ke?uoti funkcijos duomenis. Btent paskutin etap, a? ir rekomenduoiau - jo principas paprastas. Tarkim norime ?inoti kiek vartotojas para? komentar: jeigu duomen lentel nra didel, tai mums nra svarbu kaip tie duomenys bus gaunami. Taiau lentelei estint gana didelei, tai jau tampa aktualu, nes yra faktinis skaiiavimo nuostolis. Todl tokiu atveju, geriausias sprendimas - "skaitliukas", kuris para?ius kiekvien nauj komentar saugot j vartotojo ra? vartotoj lentelje. Tokiu atveju vietoje ilgo skaiiavimo, atsakym gauname vienu paprastu u?klausimu. Taip pat galime keisti atsakymo tip - tarkime norime ?inoti kiek ms tinklapyje yra ?inui. J yra keli ?imtai tkstani, ir ten +-keli tkstaniai nieko nerei?kia - atsakymus galime apvalinti. Tokiu atveju, vietoje ilgai trunkanio skaiiavimo su dbcount() galime tiesiog pakeisti ms u?klaus u?klaus su pabaiga "DESC LIMIT 1". Tokiu atveju i?rinksime naujausi duomen bazs ra? toje lentelje vos vienu u?klausimu ir taupysime krovos laik. 10.De?imtas patarimas - "Ke?uokime visk k galime" Ilgos ir didels u?klausos - tikras galvos skausmas dideliems portalams, todl paprastas to sprendimas yra tiesiog kuo didesnis u?klaus ke?avimas: 1. Ke?uokime vartotoj paie?kos rezultatus (tai aktyviai gyvendinama daugelyje kit TVS - pvz. "Invision Power Board" ar "phpBB") 2. Ke?uokime aktyvius vartotojus - kam kaskart daryti paie?kas lentelje su 80 proc. 'mirusi vartotoj', darykime jas tarp 'gyvj'. Na o mirs tarp gyvj bus automati?kai trauktas kai dar kart prisijungs. 3. Ke?uokime post skaii per par, dien, ar bendr: Algoritmas: Turbt ?iam punktui daliai ?moni gali kilti algoritmo klausimas, na argoritmo sudtingumas ia yra tiesionis O(n), tad resurs visi?kai nebenaudoja, ir skaiiuojame pasinaudodami "r?iavimas eile" r?iavimo metodu. Tam turime bti susikr papildom duom. bazs lentel, pvz.: "{prefix}_last_day_posts_cache (toliau DB_PCACHE)". su tokiu VIENINTELIU laukeliu: Name: post_time Type: timestamp Default: [V] CURRENT_TIMESTAMP Key: primary Pseudokodas: /* ra?ymas */ if(Vartotojas para?o prane?im temoje) { then if(egzistuoja lentelje ".DB_PCACHE." ra? senesni nei 24 valandos) { then i?triname visus senesnius nei 24 valandos ra?us i? ms ".DB_PACHE." lentels; } then terpiame tu?i ra? ms lentel ".DB_PCACHE."; /* Mysql atveju tai bt tiesiog komanda "INSERT INTO ".DB_PCACHE." () VALUES ()" */ } /* Skaiiavimas */ rezultatas := SUMA vis ra? tenkinani slyg ("DB_PCACHE" LENTELJE): post_time > time(); 4.Ke?uokime nari post, komentar, shout ar dar kokios kitos veiklos vykdym. 5. Ke?uokime nuotraukas, kaip tai daro TinyMCE (imagelist.js) bei vanden?enklintas nuotraukas(watermarked), kaskart taupysime serverio resursus. 6. Negeneruokime to paties skripto rezultato kelet kart - geriau saugokime j. Tarkim super sudtingas vartotojo apsaugos kod - kur kas protingiau j yra tiesiog saugoti duom bazje, o skriptu bus pasiekiamas tarkim tik koduotas pvz. sha1() jo variantas - tai u?tikrins ir saugum ir tinklapio na?um. 11.Vienuoliktas etapas(tik VPS/DS turtojams) - "Loginkime ltas u?klausas" Kartais nutinka taip, kad nariai skund?iasi, jog kartas nuo karto tinklapis labai smarkiai laggina. Tokiu atveju tiems, kurie turi VPS'us ar DS'us, rekomenduoju sidiegti kok nors padoresn "Slow-queries log" modul savo server. Tarkim "CentOS" oper. sistemai yra puikus "log-slow-queries" modulis, kuris spec. fail saugo visas ltas u?klausas, ltesnes nei X sekund?i. Taiau ?is modulis efektyvus yra kai norime rasti 'i?si?okus ltn', o ne bendrai padidinti tinklapio krovimo laik - tokiu atveju moduli logint tkstanius u?klaus ir pats ltint server. Redagavo Elektronix 2010-04-28 14:47 |
| Peršokti į forumą: |