vbet_guestcache te groot

[Ramses]

Die vbet_guestcache mag 'n goeie idee wees, maar dit is nou verskeie giga byte groot en verskeie duisendstes lêers. Was dit die bedoeling om op hierdie manier te werk?

[vBET]

Ja. Dit caches volledige HTML uitvoer - net soos dit geskryf is in parameter beskrywing. Hoeveel dit sal neem hang af van hoe groot jou forum is.

Let asseblief daarop dat jy altyd kan addisionele geïgnoreer bladsye, of net afskakel dit heeltemal jy nie uit die ruimte.

[Ramses]

Seker ek kan dit afskakel, maar ek wou die serverload te verminder. Miskien kan jy skryf in die ACS instellings dat hierdie webruimte kan blaas, kan nie almal het 25 optredes van die ruimte. Of beter om 'n manier om die grootte te verminder te vind.

[vBET]

Nie almal het selfs 1 GB vir hierdie. Soos ek geskryf het cache grootte hang af van die forum grootte. Dit caches elke moontlike forum bladsy indien nie in geïgnoreer stel. Klein forums het 'n klein hoeveelheid van die bladsye. Big forums het meer bladsye en ook meer hulpbronne.

In elk geval - dit is 'n goeie idee om mense meer bewus te wees Wat beteken dit dat die volle HTML uitvoer sal Cached en voeg daar inligting dat dit kan baie van uit die ruimte.

Oor kleiner word - ons kan voeg opsie om te zip kas lêers. Dit sal meer bediener hulpbronne wanneer die kas is geskryf, maar om dit te lees en die stuur van so 'n reaksie sal vinniger wees.
Ook kan ons voeg geskeduleerde taak wat outomaties lêers wat te oud is verwyder. Op die oomblik doen ons nie dit doen - as die lêer is te oud is, is dit eenvoudig schreven tydens die volgende versoek.

Ek is beweeg hierdie draad Feature Versoeke

[wowglider.de]

Dit sou Absolutly maklik:
Voeg 'n opsie om slegs X gigagrepe kas en verwyder dan die wat minder dikwels besoek.

[wowglider.de]

Lol, nadat ek die nuwe weergawe met die kas Ek het nog nooit gekyk hoe baie sy tot nou toe gebruik:

Debian-50-Lenny-64-minimale: ~ # DF-H
Lêerstelsel Grootte Gebruikte Gebruik maak Gebruik% gemonteer op
/ Dev/md2 688G 80G 573G 13% /
tmpfs 4.0G 0 4.0G 0% / lib / init / RW
udev 10M 764K 9.3M 8% / dev
tmpfs 4.0G 0 4.0G 0% / dev / SHM
/ Dev/md1 2.0G 86m 1.9G 5% / boot

LOL! Voor my HDD is met 8GiG gebruik! Dis "groot", btw dit lyk asof dit verkeerd caches lêers, bv:
_attachment_php_attachmentid_3350.html
_blog_php.html
_blog_php_do_list_y_2009_m_10.html

Ek dont wil kas Blogs, Tags en aanhangsels Oo

[steve]

Ek dont wil kas Blogs, Tags en aanhangsels Oo

Jy kan dit by die ignoreer opsie.

[vBET]

Dit sou Absolutly maklik:
Voeg 'n opsie om slegs X gigagrepe kas en verwyder dan die wat minder dikwels besoek.

Dit is ook 'n opsie nie. Eerstens sal ons geskeduleerde skoner en miskien rits (hierdie benadering te ondersoek) te implementeer, want hou van statistieke sal 'n invloed op die prestasie en vir ons prestasie is een van die belangrikste kwessies. - Sal ons in gedagte hou ook hierdie oplossing as 'n ander sal wees nie voldoende

[vBET]

Jy kan dit by die ignoreer opsie.

Presies - net dit byvoeg ti geïgnoreer. In elk geval dankie vir die nota - ons sal by ignoreer atachements en tags as verstekwaarde ignoreer. Blogs is iets wat baie gebruikers kan Cached nie, dus sal ons nie dit byvoeg as fedault - maar ons het dit presies instel vir sulke gevalle - jy wil iets meer om geïgnoreer te word. Dus net dit ignoreer!

[vBET]

Ook het ek net uitvind dat ons lêers benaming sjabloon kan ers en sluit in die lêernaam, doen dit van mening dat minder relevant bladsye of nie. Op hierdie manier elke dag wanneer outomatiese reiniging sal begin word, sal dit erken appropriatelly kas lêer tyd om te leef en meer lêers sal skoon. Die eerste idee was om alles skoon te maak as dit ouer as nie relevant bladsye behoort te wees. Nou sal ons die betrokke kas bladsye skoon vinniger - so jy sal ook uit die ruimte red!