Gegužė 30, 2008Paspartink savo svetainę mažiausiai dvigubai!
Pristatę knygyną, mes iš kart toli toli į priekį pasirūpinome spartos klausimu. Tiek dabar, tiek ir dar ilgai svetainė veiks greitai. Be abejo, kad aš naudoju kešavimą ir be reikalo nešvaistau serverio išteklių, tačiau sparta atsiranda ne dėl trumpo puslapio generavimo laiko (kuris retai perkopia 0.1 sekundės). Mes naudojame tokį „vaistą“, kuris vadinamas turinio glaudinimu/kompresija/suspaudimu ir aš jums įrodysiu kodėl jūsų svetainei jo reikia.
Kiekviena besiplečianti svetainė susiduria su viena opiausių svetainių problemų - maža ar nepakankama sparta. Gudrūs programuotojai prisigalvoja optimizacijų, kelių lygių kešavimų ir pan. velniavos, tačiau tai gelbsti ne visada. Pavyzdžiui didžioji dalis tinklaraščių veikia WordPress pagrindu, kuris yra gana gerai realizuotas ir puikus, tačiau daugybė tinklaraščių vis tiek veikia salyginai lėtai. Džiugas tikiuosi nepyks, jei testams naudosiu jo Nežinau.lt tinklaraštį. Tai puikus pavyzdys svetainės, kuriai pritaikius labai elementarius sprendimus galima pridėti taip norimos spartos.
Pirmasis Nežinau.lt puslapis užima nei daug, nei mažai - 700 Kb. Didžiąją dalį šios informacijos sudaro paveikslėliai, o paveikslėliai dažnoje svetainė (Nežinau.lt ne išimtis) yra patalpinami vartotojo kompiuteryje, todėl pakartotinai aplankius svetainę jie nėra parsiunčiami. Atmeskime Flash reklamas ir mums lieka 80 Kb tekstinių rinkmenų - puslapio HTML kodas, CSS rinkmena ir JavaScript skriptai. Kiekvieną kartą jums aplankius Nežinau.lt ši informacija parsiunčiama vis iš naujo. Šioje vietoje neverta ieškoti jokių kitų išeičių - turime rasti būdą, kaip informaciją vartotojui pateikti greičiau (jos nemažinant ar kitaip neprarandant).
Internetas šiais laikais yra spartus, tokį kiekį informacijos parsiunčiame labai greitai, tačiau tarkime, kad mūsų interneto planas yra standartinis ir Nežinau.lt mes parsiunčiame per sekundę. Sekundė yra mažai, tačiau naršant tarp puslapių ji juntama ir kartais labai stipriai (ypač kai sulėtėja internetas - krovimo laikas dar labiau išauga). Neverta jaudintis - sprendimas yra. Didelė sparta pasiekiama „suspaudžiant“ svetainės kodą lyg suarchyvuojant paprastą rinkmeną. Nors toks procesas kainuoja serverio išteklių, tačiau šiuolaikiniai serveriai yra pakankamai spartūs, kad su šia užduotimi susidorotų akimirksniu.
Kompresijai testuoti yra įvairiausių įrankių, tačiau man patogiausias GIDnetwork siūlomas naršyklėje veikiantis įrankis. Apsilankykite jame ir pabandykite keletą jums žinomų svetainių - tikrai ne visos jos naudos kompresiją. Minėtasis Nežinau.lt jos nenaudoja, todėl testavimo įrankis numato, kad įjungus turinio glaudinimą, parsiunčiamos informacijos kiekis sumažėtų net 70%. 70% yra daug, nes iš turėtos sekundės belieka, vos 0.3 sekundės, o tai juk daugiau nei tris kartus greičiau. Galbūt jūsų internetas yra pakankamai spartus ir tokie pokyčiai jums smarkiai neatsiliepia, tačiau yra daugybė vartotojų, kuriems tai suteiks daug naršymo „malonumo“.
Lietuvoje populiariausi Apache WEB serveriai, o didžioji dalis svetainių veikia PHP pagalba, todėl plačiau nagrinėsiu tik šiuos sprendimus. Tiek Apache, tiek PHP terpėse turinio glaudinimą galima realizuoti labai paprastai ir tam nereikia didelių žinių - Apache naudojai tegul perskaito šį straipsnį, o PHP programuotojams bus naudinga štai ši funkcija. WordPress anksčiau turėjo glaudinimo funkciją, tačiau nuo 2.5 versijos jos atsisakyta dėl to, kad nustatyta, jog PHP glaudinimas nėra pakankamai efektyvus todėl tinklaraščių savininkams naudinga perskaityti čia esančią informaciją.
Skeptikai bijo, kad suspaustos svetainės neveiks Windows 95 sistemose, tačiau juk tokie vartotojai sudaro daugiausiai 0.1% visų lankytojų. Visiems svetainių savininkams būtinai siūlau išbandyti turinio glaudinimą - tikrai išlošite patogumų vartotojui. Didelėms svetainėms tokių sprendimų taip paprastai nepritaikysi, tačiau visiems kitiems tai puikiai veikia. Patikrinta!
Patiko ką perskaitei? Užsiprenumeruok RSS srautą ir visada gauk mano naujausius įrašus pats pirmas! Tai ne tik, kad yra be galo patogu, tačiau ir leis tau nepraleisti nei vieno mano įrašo. Jei kiltų problemų - rašyk.



2008-05-30 10:23:17
Ačiū už patarimą :) 80% sumažinau kiekį maždaug.
2008-05-30 11:08:33
Heh, gerai, kad parašei, nes pastebėjau, kad tikrai, dauguma mūsų sveitainių nėra linkę to daryti ir aklai pasitiki kešavimu, kuris kartais tik pablogina situaciją. Jau keletą metų suspaudimo nauda puikiai matoma mano darbe, kur tenka dirbt su gana nemažom svetainėm, kaip pvz. administravimo įrankis, kuriame reikėjo pateikt apie 1000 eilučių gana detalios informacijos - naršyklė tiesiog atsisakydavo tai parodyti, tuo tarpu su suspaudimu jokie Timeout neįvyksta na ir daug panašių pavyzdžių.
P.S. reiktų nepamiršti paminėt, jog tiem, kam sunkiai sekasi sukontroliuot sesijas - buferis php lygyje tikrai padėtų, o tuo pačių galėtų įsijungt ir suspaudimą.
Reiktų ragint kolegas blogerius aktyviau domėtis tokiais dalykais, nes kartais nebeužtenka kantrybės naršant jų blogus
2008-05-30 12:06:57
Man tai šiaip keista, kad tiek mažai kas naudoja suspaudimą, nes tai jau yra labai senas triukas.
2008-05-30 13:17:35
0.1 sec puslapio generavimo laikas šiaip yra gana daug
2008-05-30 15:01:19
Jėga, veikia. Ačiū :) Suspaudimas 86,5% ir matosi jog greičiau krauna :) Dėkui dar kartą.
2008-05-30 15:50:37
Povilai, gana daug kam?
Paprasta svetainė žinoma, kad sugeneruojama per 0.001 s., tačiau kai didesnė svetainė 0.1 s. yra tikrai mažai. be to, šis laikas yra maksimalus ir dažniausiai neperlipa nė 0.05 s. ar pan.
2008-05-30 16:38:27
Juozai,
bet kokiam high-profile puslapiui daug. Turiu projektą, kuris puslapius išvedinėja per <0.02 sec, bet piko metu prakaituoja ir quad core xeonas.
Vien maniškis Diferior su visais “templeitais”, “multilengjudžais”, nustatymais ir kitu crap įsipaišo į 0.06 sec rėmus, o ten gi “general consumption” TVS.
2008-05-30 17:08:28
Suspaudimas sutaupo serverio resursus!
Kodėl?
Todėl, kad kuo greičiau duomenys bus išsiųsti vartotojui tuo greičiau atsilaisvins RAM’e vieta. Tuo greičiau nebus naudojamas procesorius tam klientui. Ir kt. O suspaudimas yra toks greitas, kad jis tuojau pat atsiperka.
Tikrai labai geras pastebėjimas, kad daug svetainių šito nenaudoja. Ir labai geras įrašas.
2008-05-30 17:54:33
Povilas teisus. Negalima srauto mažinti serverio ir kliento naršyklės apkrovos sąskaita. Ar bent kartą atkreipei dėmesį kiek užtrunka kompiuteris pakuodamas 700 kB? 7 MB? 70 MB?
Ilgainiui užklausų kiekiui didėjant, šis būdas tampa nepraktiškas. Geriau jau tvarkyti, sutraukti markup’ą, mažinti paveikslėlių kokybę. Situacija būtų kitokia, jeigu turėtum begalybę dedikuotų serverių kaip Google. Antra vertus, net Google nenaudoja kompresijos paieškoje. Kodėl? Leisiu paspėlioti. :)
Kęstuti, būtų viskas tvarkoje, jeigu nuorodas lankytojai spaudytų paeiliui, o ne visi vienu metu.
2008-05-30 17:59:52
noTime, dar kartą perskaityk paskutinę pastraipą, atrasi kažką naujo ;)
Tarkime http://www.engadget.com man atrodo pakankamai didelis. Be to, šis įrašas neorientuotas į tokias svetaines, kur glaudinimas kainuotų per daug ir kalbame ne apie 700 kB, o apie <100 kb ;)
Pamiršau - Yahoo.com mažas ar didelis projektas?
2008-05-30 18:12:54
Sprendimas priklauso nuo konkrečios situacijos: publikuoji daug didelių failų ir gali paaukoti šiek tiek procesoriaus laiko - spausk. Negali - nespausk.
Mano požiūris toks, kad terabaitas srauto kainuoja pigiau nei CPU upgreidas :)
2008-05-30 18:50:20
Povilai, suspaudimas kaip tik sutaupo CPU ir RAM resursus, nes tai atsiperka!
2008-05-30 18:51:15
Povilas, nesvarbu ar generuojama per 0.1 s. ar per 0.01 s. Svarbiausia, kad informacijos persiuntimas dažniausiai trunka ilgiau negu jos generavimas! Nebūtina gi gilintis į tais smulkmenas. Generavimo laikas labai priklauso gi ir nuo CPU.
noTime, Tu neteisus. Tu žinai per kokį laiką atsiunčiama informacija ir per kokį laiką generuojama informacija? Manau ne. Spėk per kokį laiką RAM’e stovintis 100 MB mano 800 MHz CPU perkonvertuoja į gzip? Rezultatai tave tikriausiai šokiruos. Siūlau pačiam pamėginti, nes tikriausiai mano skaičiais nepatikėsi. Tik būtina, kad ta informacija prieš tai būtų įkelta į RAM-ą ir tik tada pradedamas laiko atskaitos taškas ir generuojama į gzip’ą. Šiuo atveju turėsi naudoti linux’us (aišku galima ir windows, bet…).
Kaip tik būtent dideliuose projektuose kur kiekvieną sekundę užklausų būna dešimtys, šimtai ar tūkstančiai būtent kaip tik tai padeda atlaisvinti CPU (nes kol nenusiųsti duomenys tol apkraunamas CPU bei RAM, kuo greičiau bus jie nusiųsti tuo greičiau galima bus pradėti vykdyti naujas užklausas, o spaudžiant tekstą jis labai pagreitina siuntimą, nes dažniausiai tekstas srautą suvalgo, na nebent jeigu projektas toks, kad ten yra labai žiauriai dideli ir nežmoniški IMG failai, bet visada juos galima sumažinti).
Google aplamai duomenis kur tik gali siunčia suspaustus. Duok konkretų pavyzdį kur jie nespaudžia duomenų, nes kitaip laikysiu tai kaip bandymą pasirodyti protingesniam šnekant nesąmones
2008-05-30 18:55:45
Kęstuti, nelabai suprantu kaip procesoriaus apkrovos didinimą galima vadinti resursų taupymu :) Tavo argumentas apie RAM atkrenta, nes apache visų pirma sugeneruoja puslapį tokį, koks jis bus nesuspaustas ir tik tada, PAPILDOMAI, spaudžia visą contentą.
2008-05-30 20:21:01
Išanksto atsiprašau už netvarką tekste, nes neturiu laiko tobulai paaiškint kas ir kaip.
Povilai, jei tik šitaip skaičiuoji tada taip.
Bet CPU yra toks dalykas, kad jo apkrautumas nebūna 100 %, o jis visada labai žiauriai šokinėja. Iš esmės jo neįmanoma normaliai pavaizduoti grafiškai.
Serverio galingumas skaičiuojamas ne tik pagal CPU galingumą, o pagal tai kiek užklausų gali įvykdyti per sekundę gali įvykdyti.
Kodėl su tuo pačiu kompu ir tik pridėjus spaudimą galima padaryti daugiau užklausų?
HDD lėti ir į juos kreipimosi nepavyks išvengti.
RAM - yra greita, bet deja jo nepadarysi tokio pat dydžio kaip HDD.
Nepamirštam, kad RAM’as visada būna 100 % užimtas.
Kompas: RAM’as 1 GB, HDD 10 GB, CPU pvz.: 1 GHz (turiu omenyje lėtas).
Taigi manykim nėra kompresijos ir ateina iš lankytojų 10 užklausų:
RAM’e laikoma mažiau HDD cache todėl, kad prieš tai buvę užklausos dar neišsiųstos vartotojui ir jos nesuspaustos, o tai reiškia daugiau vietos užima RAM’e dar neišsiųsta info (generavimas trunka gi greičiau negu nusiuntimas vartotojui ir ne vieną gi kartą). Kol laukiama info iš HDD -> RAM -> CPU per tą nuėjimą laiką jeigu CPU buvo neapkrautas 100% visą laiką kas sunkiai įmanoma reiškia tas CPU galingumas išnyko. Taigi pradėjo vieną užklausą generuoti, pradėjo kitą (CPU apkrautumas sakykim 100 %) į tai laiką jau seniai spėjo dar ateiti 10 užklausų tokių pačių užklausų ar kitokių dalis jų negali vykdyti ir laukia savo eilės dalis HDD’ą kirkina, todėl išnykus tiems aniems CPU resursams šičia jau nebepakanka CPU, kai jo nebepakankama kol laukiama eilės - tikrinamas CPU užimtumas ir kiti dalykai kas nemažai resursų valgo vėlgi CPU greitis krinta, ateina dar 10 užklausų ir dar padidėja eilė, RAM’e HDD’o cachas mažėja, daugiau kreipiamasi į HDD’ą, o kol kreipiamasi vėl dingsta CPU resursai. Galiausiai gali susidaryti tokia eilė, kad visa tai daugiau RAM’o užima negu HDD’o, o CPU resursų daug išnyksta dėl visokių tikrinimų ir kitų dalykų.
Bandau paaiškinti paprastai, bet tai sunku padaryti.
Aišku aš dar neįtraukiau pagal failus kaip viskas vykdosi. Vėlgi tai būna dažnai vienos užklausos generavimas taip: (HDD->)RAM->CPU vėl (HDD->)RAM->CPU vėl (HDD->)RAM->CPU vėl (HDD->)RAM->CPU, nes būna ne vienas failas, o jų dešimtys.
Kai susidaro per daug eilėje užklausų (užklausos eilė irgi užima vietą) serveris pasidaro labai lėtas.
Kai būna suglaudinta:
tada kas būna daugiau išsisaugo CPU resursų dėl to, kad būna daugiau RAM’e HDD’o cachintos info, nes sugeneruoti failai kuriuos siunčia vartotojui mažiau užima ir be to dar ir trumpiau užsibūna serveryje, nes greičiau išsiunčia mažesnį kiekį info. Todėl lieka daugiau vietos HDD’o cachui, o jis konkrečiai būna overwridintas tos informacijos kuri yra svarbesnė pvz.: svetainės sugeneruotas kodas, kliento IP ir visa kita. O 100 sugeneruotų užklausų * 0.5 MB = 50 MB, o tai yra overwridintas HDD’o cache.
Tekstas vidutiniškai spaudžiasi apie 89 %.
Vartotojai dažniausiai turi apie 1 Mbps konvertavus į kitus vienetus telieka 128 KBps greitį, o tai reiškia 128 KB sveriančią svetainę siunčia NET 1 s., o tuo tarpu svetainės generavimas trunka TIK pvz.:0.1 s.!!!
Be to siunčiant info vartotojui CPU užima ir whiliniai tikrinimai ir pergeneravimai, kuo ilgiau užima siuntimas tuo daugiau CPU apkraunams whilais.
RAM-as labai pagreitina veikimą ir kuo jo daugiau tuo geriau, jeigu svetainė sugeneruota ji laikoma RAM’e tol kol bus galutinai nusiųsta vartotojui (jei ji suspausta ji mažiau užima net ir vietos pačiame RAM’e). Svetainės generavimo laikas labai priklauso ir nuo to ar visa jos informacija sukaupta RAM’e jei ne ir reikia kreiptis į HDD tai labai ilgai užtrunka (aišku ne tiek ilgai kaip siuntimas vartotojui).
2008-05-30 20:30:21
Beje jeigu naudoji cache geriausia jį saugoti suglaudintą į HDD’ą, nes tik iš saugoti ilgiau užtrunka, negu suglaudinti ir išsaugoti.
2008-05-30 20:37:29
Kęstuti,
Tu studijavęs žemo lygio programavimo kalbas, kompiuterio dalių veikimą ir TCP protokolą ar kalbi ‘out of the ass’, kaip sakoma?
Išjunk savo httpd keepalive ir demonas uždarys soketą tuoj pat kai išsiųs duomenis.
All in all, nenoriu likti šališkas. Kaip jau sakiau, viskas priklauso nuo situacijos.
2008-05-30 20:44:53
100 KB suspaudžia pas mane per 0.0001 s. Tavo manymu tai labai daug resursų naudojantis procesas? Pas mane Drupal generuoja vien 0.1 s., o čia pamanyk suspaudimas 0.0001 s. užtrunka…
2008-05-30 20:53:15
Turi būti kuoktelėjęs mechanizmas, kad sugebėtum atrasti santykį tarp visų kompiuteriuose vykstančių procesų ir pasakyti, kad čia kažkur ketvirtadaliu sekundės kažkas vyksta greičiau. Nesame mokslininkai ir neturime tam tirti nė patirties, nė įrankių.
Iš mano perspektyvos vaizdas atrodo toks: prieš siųsdamas markup’ą, serveris pasigauna failą, jį suspaudžia iki geriausios kompresijos, tik tada išsiunčia klientui, klientas išsipakuoja, nors suspaudžia tik markup’ą, kuris visas neužima daugiau nei nedidelis paveikslėlis.
Nesu nusistatęs prieš kompresiją, tačiau, dovanokit, nematau jokių turbo pagreitėjimų, tik abejotiną fizinių resursų švaistymą.
Vis gi norint puslapį pamatyti blicu (čia matau dėl to jūs alpstate), reikia vengti pliko XHTML ir echo - viską į ekraną šutinkite tik po visų skaičiavimų arba, jei nekankinant savęs, nustatyti pačią prasčiausią kompresiją.
2008-05-30 21:07:28
noTime, Įrankiai matavimui yra, nors jie nėra 100 % tikslūs.
Išpakavimas trunka trumpiau negu suspaudimas. Kaip sakiau pas mane 100 KB spaudžia per 0.0001 s.
Lietuvoje dažniausiai žmonės turi kaip sakiau 1 Mbps, o tai reiškia, kad jiems 128 KB siunčia net 1 s.
Jei tai tau atrodo resursų švaistymas tada kam objektinis programavimas - jis švaisto resursus. Kam tada design patterns, švaisto resursus - daugiau resursų išvaisto negu kompresija.
2008-05-30 21:14:26
Šiais laikais žmonės daug ko prisigalvoja idant palengvinti sau gyvenimą. Tegul pečiui sueikvosiu daugiau malkų, bet tegul jos pačios į jį ir įlipa. :)
2008-05-30 21:21:17
noTime, Teisingai pastebėta. Bet kartu ir žmonės negali būti be darbo. Dabar kai toki laikai ir tokia technika galima būti dirbti tik max., 4 val., tai ne. Reikia dirbti 8-ias ir tuos pinigus iššvaistyti.
2008-05-30 22:06:36
Sakyčiau, čia tik vienas iš keleto žingsnių į idealų veikimą ;)
http://developer.yahoo.com/performance/
Kas dėl iškeitimo serverio resursus į kliento resursus: ar čia tik man taip atrodo, ar serverių apkrovos yra gerokai didesnės nei mano PC, kuris 50% CPU pasiekia tris kartus į valandą, ir man tikrai nepasijaus papildomas krūvis išarchyvuojant gzip’ą…
2008-06-01 15:07:48
“Atmeskime Flash reklamas ir mums lieka 80 Kb tekstinių rinkmenų - puslapio HTML kodas, CSS rinkmena ir JavaScript skriptai. Kiekvieną kartą jums aplankius Nežinau.lt ši informacija parsiunčiama vis iš naujo. Šioje vietoje neverta ieškoti jokių kitų išeičių - turime rasti būdą, kaip informaciją vartotojui pateikti greičiau (jos nemažinant ar kitaip neprarandant).”
Klaida. JavaScript ir CSS failai yra nedažnai atnaujinami, todėl juos visiškai taip pat kaip ir paveiksliukus galima saugoti naršyklės cache’e, tad belieka tik pats html dokumentas.
2008-06-02 03:22:55
“Kuo daugiau sunaudoji jėgos, tuo mažiau reikia kelio.” - 7 klasės fizika.
Tiek prasmės ir visam ginče: kompresija naudoja CPU, nespausti duomenys naudoja bandwidth’ą. Pasižiūri ko labiau trūksta ant svetainės piko - įjungi mod_deflate arba išjungi.
Kęstučiui: atvirkščiai, išpakavimas visada trunka ilgiau negu suspaudimas (http://trappist.elis.ugent.be/~wheirman/compression).
2008-06-02 11:01:49
Manfredai, tai, kad pagal tavo nuorodą išpakavimas greitesnis negu suspaudimas. Ypač pagal lentelę gale. Tiesa sakant, nelabai įsivaizduoju kaip suspausdimas gali būti greitesnis už išpakavimą.
2008-06-02 13:20:44
Manfredas, dėl jėgos tai jos žiauriai mažai reikia palyginus su tuo kiek laiko generuojama svetainė. O šiais laikais CPU tokie greiti, kad jiems iš esmės beveik 100 % rašomi neefektyvūs sprendimai. Tokiems projektams kaip wikipedia nereikia nė 50 serverių, o jie patys naudoja suglaudinimą. Mano nuomone geriau jau 50 Lt daugiau investuoti į CPU galingesnį ir už tą 50 Lt naudoti suglaudinimą.
Beje ar žinai ką daro kai glaudina informaciją? Taigi ieško pasikartojančių dalykų ir juos užrašo „formule“, o išspaudimas tik tiek, kad pagal formulę viską sudėlioti.
2008-06-03 03:19:56
Atsiprašau dėl to suspaudimo/išpakavimo greičio, tiek Dalius, tiek Kęstutis ten teisūs (yra ir išimčių iš taisyklės, bet čia jau ekstremumai - http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html); blogas įprotis komentuot naktį.
Kaip bebūtų, laikausi nuomonės, kad reikia žiūrėt, kieno apkrova didesnė - linijos, ar CPU, ir vien pagal tai spręst, ar reikia jungt kompresiją, ar ne. Jeigu (ir, IMO, dažniausiai) labiau užkimšta linija (o CPU apkrova šuolinė, ir ne itin aukštu bendru vidurkiu, kaip irgi dažniausiai yra) tai tada kompresija tampa labai naudingu įrankiu apkrovos valdymui, tuo labiau, kad santykis tarp “pralošto” CPU laiko ir “išlošto” siuntimo laiko gana nemažas, ką ir sakė Kęstutis; plius dalis skaičiavimo krūvio persikelia ant vartotojo išpakuojant, kas irgi yra gerai iš serverio savininko pozicijų. ;-)
2008-06-03 14:42:09
Manfredai, aš spaudimą labiausiai turiu omenyje tam, kad pagreitinti svetainės darbą (suspaudimas ir išpakavimas labai trumpai trunka, o siuntimas vartotojui labai ilgai, ypač jei tai daroma iš užsienio serverio, jeigu iš MegaNet į MegaNet tada spaudimas nereikalingas [Zebra internetas bene populiariausias Lietuvoje]). Ir tik tada galima šnekėti, kad va čia mažesnio Mbps reikės ir už tai mažiau mokėt reikės dėl to, kad va linija atlaisvės ir pan.
2008-06-08 22:26:16
reikia ziureti kas pigiau: ar elektra ar slanga ..
2008-07-16 11:01:58
kompresavimas atsiperka tik tada, kai yra nedidelis kanalas, o resursų daug. O šeip, statinis contentas turi būti pateikiamas per CDN’ą, galima roundrobin DNS’ą turėt, visa kita ngnix arba lighttpd, jeigu reikia apache, nebent fowardinti arba reversinti trafficą, o didžiaja dali tinklapio tiesiog reikia pateikti statiniu budu. Su amd 4200 ir 2gb ram be raido tarp 12-15k rekvestu/s manau tai geras rezultatas ;]
2008-07-29 18:40:02
Tai gal koks plugin yra wordpress ar alternatyvus būdas? nes ten reik turėti priėjimą prie servo, o jei turi tik eilinį host su cpanel…
2008-07-29 18:57:12
Wordpress naudotojams veikia šis - http://userfirstweb.com/246/wordpress-25-removes-gzip-option/
2008-07-30 16:24:38
Aha, vBulletin forume by default GZIP 1, tai nustačiau 9, kai piso puslapius nuo 200kb iki 30kb!!! Dabar kaip žaibas vartos tie puslapiai! :))