Tinklapio našumo optimizavimas - WordPress, Shopify ir PHPFusion programuotojų bendruomenė

Navigacija

Vartotojų tinkle

Prisijungusių svečių: 40
Prisijungusių narių: 0
Prisijungusių narių nėra

Registruoti nariai: 25,952
Naujausias narys: tomeem

Naujausi straipsniai

Įprasti:

IMG BBKodas

Pamoka ,nemokamo php...

HTML lentelės

Išnykstanti reklama

Kalendorius

Skirti naujokams:

Mano profilis įdėj...

PHP-Fusion V7.02.03 ...

Keletas pamokėlių ...

Paskutiniai nariai

tomeem	1 savaitė
Reikalas	2 savaitės
weberiz	4 savaitės
mRokass	7 savaitės
kartoonas	8 savaitės
iaescortsmap	8 savaitės
ozzWANTED	9 savaitės
grunskiz	10 savaitės
Bruksnys	11 savaitės
illusion	11 savaitės
ordo	12 savaitės
Jurgaila	13 savaitės
originalcs16	13 savaitės
Rytis	13 savaitės
halis	15 savaitės
junkus	18 savaitės
morlis	18 savaitės
Majakas	19 savaitės
andsoft	20 savaitės
picolee90	21 savaitės

Informacija:

OS: Unknown
Naršyklė: Nežinoma
IP: 3.17.150.163
Naujienų: 529
Straipsnių: 235
Temų: 52,584
Postų: 522,522
Postų pask. parą: 0
Shout'ų pask. parą: 0
P.S.C. pask. parą: 0
Nuorodų kataloge: 13

Lankomumo Statistika

Peržiūrų šiandien: 22

Iš viso peržiūrų: 22948724

Prisijungti

REGISTRUOTIS

Pamiršai slaptažodį?
Paprašyk naujo
Aktyvuoti save

Šaukykla

Jei norite rašyti žinutes, turite prisijungti.

ozzWANTED
2024 Sau. 17 01:01:00
Desperatiškus komentarus šaukykloje su accountu po mėnesio prasibuvimo, ištryniau. Pasaulis ir taip juodas. Įjungiam šviesą, prašviesės.

Majakas
2023 Gru. 10 19:12:39
Negaliu patikėti jog žinutės/pranešimai visi yra nuo 2008 m

Žmogus
2023 Rugs. 7 21:09:14
O gal BloodKiller pasijungs?

Apocal
2023 Rugs. 2 18:09:23
Nu davai nuveikiam kažką

. Prisijungti kada visi čia

.

Apocal
2023 Rugs. 2 00:09:18
Šiaip atėjau pažiūrėti ar dar lopas nesby yra ar koks ten buvo.

Šaukyklos archyvas

Apklausa

Archyvas

Reklama 400x60

Automatizuotas hostingas

Tinklapio našumo optimizavimas

Šis straipsnis tiems, kurie turi didelius projektus paremtus Php-Fusion sistema. Tai yra, kai įrašų skaičius lentelėse pradeda viršyti 100k.

Taigi, bedarydamas updeitus šiam tinklapiui, vienas jų yra pabandyti jį kažkiek optimizuoti. Kadangi šitas didelis dramblys pasidarė labai lėtas kaip pradėjo 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 būtų - "spauskime srautą" (maincore.php):

ob_start();

eilutės keitimas į

 ob_start(ob_gzhandler);

Šis žingsnis mums leidžia persiųsti tinklapio srautą vartotojui suspaustu pavidalu. Tai gana ženkliai įtakoja krovimo laiką.

Beje, įdomumo dėlei yra ir kitų srauto spaudimo būdų, ne tik "ob_gzhandler", tačiau šis yra, matyt, populiariausias.

2.Antrasis etapas - "sudėkime indeksus"

Kad suprastumėte, kada ir kur tai daryti, nėra 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, skaičiuojame 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 sudėkime "INDEX" tipo raktus(KEY's) daugiausiai naudojamiems laukeliams.

Kaip pavyzdį tarkim, galime paimti "online_ip" iš lentelės "{prefix}_online", bei "user_ip" iš lentelės "{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 sudėti indeksus šiems lentelių laukeliams yra pravartu.

Toliau iš aktualių būtų galima paminėti:

"thread_id" lentelėje "posts" (kadangi dažnai grupuojame postus pagal temą)

"user_name" lentelėje "users" (dažnai ieškome vartotojo vardo)

ir daugelį kitų.

Esmė paprasta - sudėkite kuo daugiau į paminėtus punktus patenkančių indeksų. Žinoma persistengti neverta, nes vieno indekso teikiama nauda su kiekvienu nauju lentelės indeksu mažėja.

Kritiniais variantais toks indekso padėjimas tinkamoje vietoje gali sumažinti tinklapio krovos laiką nuo 15-16 sekundžių, iki vos 1-2 sekundžių.

3.Trečio etapo esmė - "NESIRINKIME nenaudojamų laukelių":

Šio punkto esmė manau labai puikiai suprantama - kalbu apie užklausos, į duom. bazė, dalį "SELECT (laukelių sąrašas)". Jeigu Jūsų tinklapis pilnas SELECT * tipo užklausų - vadinasi esate tikrai neoptimizavęs tinklapio ir bereikalingai švaistote serverio resursus.

Pagal idėją, "SELECT laukelis1,laukelis2 " ir t.t. turėtų būti tik tie lentelės laukeliai, kuriuos iškviesite žemiau seksiančioje funkcijos implementacijoje, ar bet kokiame kitame informacijos iš duom. bazės 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 sudėti buvo, tai galite tikėtis 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žiūrų padaro, ar dar kada lankėsi pastaruoju metu ir t.t.

Pradžioje galbūt nieko ir nejausime, tačiau tinklapiui esant populiaresniam po pusmečio ar metų, mūsų log'ų lentelės pradės daryti griozdiškos, iš nejučiomis nepajusite kaip tinklapio krovos laikas pradės ilgėti. To esmė, ilgos paieškos didelės apimties lentelėse. Taip čia duoda naudos būtinų laukelių SELECT dalyje apibrėžimas, indeksų sudėjimas ir t.t., bet 'net ir geriausias vairuotojas neįvarys mašinos į už mašinos plotį siauresnį garažą'. Todėl, geriausia tokiu atveju išeiti - failo pabaigoje pasirašyti papildomą užklausą, kuri, tarkim Jūsų 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, tačiau tikrai neįtakos tinklapio darbo, be to darant duom. bazės kopijas, nereiks siųstis kaskart(užteks tik vieną - pradinį kartą) milžiniško dydžio bylų - UŽARCHYVUOTŲ lentelių turinys tampa statiniu ir nekeičiamu. Tačiau papildomo failo pagalba, galite suteikti administratoriui kartas nuo karto pasižiūrėti į 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. bazės lentelėms. Dažnai atsitinka, kad dėl ryšio trukių, ar serverio trikdžių ar šiaip kokių problemų įsivelia klaidų ir atsiranda duomenų perteklius duom. bazės lentelėje, kartais perteklius gali būtų ir keliasdešimt megabaitų, jeigu lentelės 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":

Būtinai 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, tačiau čia pamiršama smulkmena - kaip viena eilutė yra pateikiama informaciją apie bendrą sutapimų skaičių - 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, tačiau mes galėsime išlošti sistemos resursų bemaž dešimteriopai įdėję į mūsų rezultatų skaičiavimo užklausos pabaigą kodą "[b]LIMIT 501".

7.Septintas etapas - "Protingai pasirinkime ORDER BY reikšmes":

Šio etapo esmė - nedėkite 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 lentelės dydis yra 10 tūkst. atributų, o kitos lentelės dydis - 500 tūkst. atributų, ir abi lentelės turi datos laukelį, pagal kurį Jūs 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 būtų 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 - "Rinkimės 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 tūkst. eilučių, antrosios - vos 10 tūkst, trečiosios - vos 20 įrašų.

Todėl 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 eilučių lentelėse kiekybinio santykio.

PATYRUSIEMS VARTOTOJAMS (expert-users)

9.Devintas etapas - "Sekime užklausų "Load time".

Šį dalyką įgyvendinti gana paprasta - pasiimkite bet kurią iš microtime() funkciją reazijuojančių mikro-laiko laikmačių skriptų(funkcijų) ir tiesiog saugokite:

--> Bendrą tinklapio krovos laiką ("START" pradžioje po pirmųjų eilučių maincore.php faile [PRIEŠ visas mysql užklausas ir bet kokias skaičiavimo funkcijas], "END" pabaiga theme.php footer dalies pabaigoje [PO visų mysql užklausų ir bet kokių skaičiavimo 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, galėsite nesunkiai matyti kuriose būtent vietose susidaro "tinklapio butelio kakliukai" arba "silpnieji taškai". Nesunkiai analizuodami gautą informaciją galime nuspręsti ką daryti su lėtomis 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 tobulesnės sistemos ar modifikacijos, kuri atliktų tą patį darbą su kur kas geriau paruošta duomenų struktūra ir saugojimu

d)Saugoti funkcijos rezultatą, ir kviesti ją rečiau.

e)Keisti atsakymu tipą (jeigu kalbame apie dbcount(), tai keičiame į "DESC LIMIT 1");

f)Kešuoti funkcijos duomenis.

Būtent paskutinį etapą, aš ir rekomenduočiau - jo principas paprastas. Tarkim norime žinoti kiek vartotojas parašė komentarų: jeigu duomenų lentelė nėra didelė, tai mums nėra svarbu kaip tie duomenys bus gaunami. Tačiau lentelei estint gana didelei, tai jau tampa aktualu, nes yra faktinis skaičiavimo nuostolis. Todėl tokiu atveju, geriausias sprendimas - "skaitliukas", kuris parašius kiekvieną naują komentarą saugotų jį vartotojo įrašę vartotojų lentelėje. Tokiu atveju vietoje ilgo skaičiavimo, atsakymą gauname vienu paprastu užklausimu.

Taip pat galime keisti atsakymo tipą - tarkime norime žinoti kiek mūsų tinklapyje yra žinučių. Jų yra keli šimtai tūkstančių, ir ten +-keli tūkstančiai nieko nereiškia - atsakymus galime apvalinti. Tokiu atveju, vietoje ilgai trunkančio skaičiavimo su dbcount() galime tiesiog pakeisti mūsų užklausą į užklausą su pabaiga "DESC LIMIT 1". Tokiu atveju išrinksime naujausią duomenų bazės įrašą toje lentelėje vos vienu užklausimu ir taupysime krovos laiką.

10.Dešimtas patarimas - "Kešuokime viską ką galime"

Ilgos ir didelės užklausos - tikras galvos skausmas dideliems portalams, todėl 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 lentelėje su 80 proc. 'mirusių vartotojų', darykime jas tarp 'gyvųjų'. Na o miręs į tarp gyvųjų bus automatiškai įtrauktas kai dar kartą prisijungs.

3. Kešuokime postų skaičių per parą, dieną, ar bendrą:

Algoritmas: Turbūt šiam punktui daliai žmonių gali kilti algoritmo klausimas, na argoritmo sudėtingumas čia yra tiesionis O(n), tad resursų visiškai nebenaudoja, ir skaičiuojame pasinaudodami "rūšiavimas eile" rūšiavimo metodu.

Tam turime būti susikūrę papildomą duom. bazės 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 lentelėje ".DB_PCACHE." įrašų senesnių nei 24 valandos) {


      then ištriname visus senesnius nei 24 valandos įrašus iš mūsų ".DB_PACHE." lentelės;


   }


  then


   Įterpiame tuščią įrašą į mūsų lentelę ".DB_PCACHE.";


/* Mysql atveju tai būtų tiesiog komanda "INSERT INTO ".DB_PCACHE." () VALUES ()" */


}


/* Skaičiavimas */


rezultatas := SUMA visų įrašų tenkinančių sąlygą ("DB_PCACHE" LENTELĖJE): 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 sudėtingas vartotojo apsaugos kodą - kur kas protingiau jį yra tiesiog saugoti duom bazėje, 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 turėtojams) - "Loginkime lėtas 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 lėtas užklausas, lėtesnes nei X sekundžių. Tačiau šis modulis efektyvus yra kai norime rasti 'išsišokusį lėtūną', o ne bendrai padidinti tinklapio krovimo laiką - tokiu atveju moduli logintų tūkstančius užklausų ir pats lėtintų serverį.

-----------------------

Tikiuosi šis straipsnis Jums padėjo.

Atnaujinta: 2010-02-03

ozzWANTED Copyright © 2009 ; PhpFusion-Lt.com Copyright © 2009

Straipsnio informacija

Autorius
ozzWANTED

Parašymo data
2009 liepos 3 00:07:27

Komentarų
24

Skaityta
4014

Spausdinti

Komentarai

ozzWANTED 2009 liepos 3 00:07:59
Na va, seniai žadėjau parašyti kažką gero ir naudingo. 10k simbolių

Tikiuosi pravers.
Beje, idomumo dėlei, šiuo metu panelė "INFORMACIJA:" yra nekešuota, ir localhoste užleidus load time check'ą jai rezultatai buvo kraupūs:

Bendras tinklapio krovos laikas: 1,37 sec
Panelės "Informacija" krovos laikas: 1,03 sec

Po saito updeito, bent jau vieną sekundę load time'o būsim išlošę

bad_user 2009 liepos 3 00:07:07
O paskaitinėsim gal kas pravers

ozzWANTED 2009 liepos 3 00:07:23
Papildytas 8 etapu

bad_user 2009 liepos 3 00:07:17
1 dalykas atvedė mane į protą. Sumažinsiu dbcount funkcijų iki minimumo

frix 2009 liepos 3 00:07:18
Paskaitinėjau. Tiesa, ne viską, bet būtinai pabaigsiu, nes tai, ką perskaičiau, sudomino. Regis šiuo atveju kokybė tikrai pranoko kiekybę.

----------------------------------
Redagavo frix 2009 Lie. 3 00:07:02

nbanba 2009 liepos 3 09:07:33
Va, čia tai straipsnis

. Ačiū

Pakartoti slaptažodį 2009 liepos 3 17:07:10
Labai fainas straipsnelis, daugiau tokių.

ozzWANTED 2009 liepos 3 19:07:47
Papildžiau patarimą nr.7. Kadangi manau daugumai aktualu, parašiau savo sugalvoto algoritmo, paskutinės paros postų skaičiaus kešavimui, pseudokodą.

Manau pravers

Na o straipsnio ilgis išaugo jau iki beveik 11,5k ženklų

))
----------------------------------
Redagavo ozzWANTED 2009 Lie. 3 20:07:23

mXt 2009 liepos 3 20:07:03

Na o straipsnio ilgis išaugo jau iki beveik 11,5k ženklų

Tu gal ir snaiges, kurios nukrenta ant palangės, žiemą po vieną suskaičiuoji?

ozzWANTED 2009 liepos 3 21:07:56
Kad mėgstu labai statistikas, visiems seniai manau žinoma. Viename savo projektų, tam ne visą forumo kategoriją esu paskyręs.

_Tomas 2009 liepos 4 00:07:51
O kur green-users

ex-it 2009 liepos 5 00:07:52
Daug skaitymo, pora eiluciu paskaiciau ir pavargau, o dabar noreciau paklausti, ar kiek nors yra skirtumo ant apkrovimo tarp tokio if'o

if($a=='asd' && $b =='hfgs') echo bla;

ir keliu ifu su ta pacia reiksme..

if($a=='asd') if($b =='hfgs') echo bla;

Kuris yra optimalesnis? Suprantu gal kam ir kvailai pasirodys, bet man idomu suzinoti ar turi reiksmes tai :}
----------------------------------
Redagavo ex-it 2009 Lie. 5 00:07:08

ozzWANTED 2009 liepos 5 01:07:59
Mastyk archtektūriškai - vienas ASCII simbolis = 2 baitai, t.y. 16 bitų, 1 uft-8 simbolis = 3 baitai, t.y. 24 bitai. Vieno bito reikšmė gali būti 0 arba 1(hdd atveju, lastelės poliškumas teigimas, arba lastelės poliškumas neigimas)

taigi, jeigu darai

if($a == "ABCDEF")

Tai tavo sistema, skanuos kiekvieną simbolį lygindama su $a reikšme(kuri yra saugoma RAM'e, kadangi $a yra STRINGAS, tai tavo $a bus tik refferencas į stringą su ilgiu, t.y. patekęs į RAM sritį jis turės kaskart pavažiuoti vienu segmento registru tolyn.
Taigi, realiai ši tavo operacija atliks 6 ram kvietimus, kurių kiekvienu atveju bus atitinkamai keičiamas nuorodos į RAM adresas, pvz. 0x0562dh (h - hexdecimal žymuo), toliau bus atitinkamai 0x0562dh + 02h = 0x0562h
Taip pat tiek lygiai tiek pat operacijų bus ir stringo lyginime su duomenimis HDD, kadangi tai yra failo kodas. Taip pat bus viena operacija rezultato gražinimui, t.y. gruobiai tariant toks palyginimams naudos 13 operacijų, + visa kita priklauso jau nuo programming language, nes ten dar dideli waste'ai būna.

Taigi, atsidaręs vieną if() {} sistema į jo vidų žiūrės tik jeigu atsakymas bus true(t.y. 1), jeigu darysi vieną užklausą, vienuose skliaustuose, tai tikrinimas Php/C++ atveju sustoti gali dvejuose vietoje:
-> nuskaičius "&&" (tokiu atveju jeigu pirmoji dalis gražintų atsakymą FALSE (t.y. 0) ir tolimesnis tikrinimas jau būtų beprasmis, ir iškart darytų JUMP'ą(arba call'ą, čia priklauso nuo programming language, nes vėlgi JUMP'o max. ilgis ribotas),
-> arba nuskaičiuos abu if() elementus, t.y. atveju jeigu pirmas gražintų TRUE, t.y. 1. Šiuo atveju, tavo nuostolis resursų butų visas operacijų skaičius, pradedant "&&", jeigu antrasis elementas gražintų FALSE, visais kitais atvejais nuostolio nebūtų.

Beje, if'ai tau sunodoja maždaug:
0,0005 sekundės
standartiškai kiekvienas(žinoma priklauso ką lygini, bet kalbu apie konkrečiai šį atvejį greičiaisiai), taip kad tokios smulkmenos neturi prasmės, nebent pas tave ten tų if'ų koks 400-500.
----------------------------------
Redagavo ozzWANTED 2009 Lie. 5 01:07:15

MAnjack 2009 liepos 8 18:07:06
Straipsnis išties geras. Pas mane saituose pusė šio straipsnio tikrai padaryta, gal net daugiau

Langas 2009 liepos 8 22:07:21
Niekaip neperprantu ką reikia daryti 2 ir 3 straipsnyje

_Tomas 2009 liepos 21 05:07:08
Sakau, kad reikia (green-users) dalies

edis2 2009 liepos 21 13:07:34
labai geras straipsnis ozz

Šaunu

adulis 2009 rugpjūčio 2 22:08:20
Geras straipsnis, nors ir nevisus punktus dariau bet puslapio užkrovimas dabar sumažėjo beveik per pus.

Kelmas 2009 rugpjūčio 29 11:08:40
Šeip dbcount'ą galima patobolinti, kad juo būtų galima naudotis ir toliau. Tik reikėtu keisti dbcount funkciją į šita:

function dbcount($fields, $table, $cond = "") {

$query = dbquery("SELECT $fields FROM ".DB_PREFIX.$table".($cond != "" ? " WHERE $cond" : ""));

return dbrows($query);

}

Tada reikėtu perašyti visus dbcountus esančius fusion'e. :)
----------------------------------
Redagavo Kelmas 2009 Rugp. 29 11:08:15

_Tomas 2009 rugsėjo 30 19:09:18
Kai IV perėmė Tinkalapis.net pradėjo puliuoti su ob_start(ob_gzhandler);

ozzWANTED 2010 vasario 3 04:02:56
Papildžiau 6,7 ir 8 punktais. Kadangi dariau šio saito paieškos sistemos optimizavimus didžiausią poveikį padariusius punktus patalpinau.

Ypač aktualus ORDER BY šį kartą buvo(nes su LIMIT jau seniau buvau sutvarkęs):
Pakeitus "ORDER BY post_datestamp" į "ORDER BY thread_lastpost" kai kurių užklausų laikas sumažėjo nuo 3,5 sek. iki ~0,08sek.

Creatium 2010 lapkričio 4 12:11:54
Yra toks įrankis (papildinys) Firefox naršyklei "YSlow". Labai geras. Parodo praktiškai viską. Taip pat rodo ir kiek HTTP užklausų vykdoma pirmą kartą apsilankius, kiek antrą kartą. Kiek ir kas yra kešuojama. Ir pagal jo duomenis, tai šitam puslapyje galima būtų sukešuot nemažai paveiksliukų, kas manau tikrai nemažai padidintų krovimo greitį. Taip pat ir headerių sutvarkymas (iš dalies per kešavimo).

weberiz 2011 rugpjūčio 25 02:08:55
ozzWANTED
žiuriu nebloga komentara palikai kuris mane albai seniai domino kaip apskaičiot php mysql ir viska kas su serveriu hyppertext procces'u susije be html goto js i pan kiek naudoja procesoriaus ramu kiekius baitais arba bitais

aš šito pasauliu domios esu 17metu ir bandysiu tuo siekt gyvenime

tai toks straipsnis man praverstu

gal koki generatoriu pagaminsiu kuris apskaičiotu php komadu faile resursu surijima

Jaunelis 2012 vasario 10 11:02:28
Ech padėjo tai jau tikrai šis straipsnis.

Rašyti komentarą

Prisijunkite, norėdami parašyti komentarą.

Reitingai

Balsuoti gali tik nariai.

Prašome prisijungti arba prisiregistruoti.

Nuostabu!	100%	[2 Balsų]
Labai gerai	0%	[Nėra balsų]
Gerai	0%	[Nėra balsų]
Patenkinamai	0%	[Nėra balsų]
Blogai	0%	[Nėra balsų]