A vbet_guestcache lehet jó ötlet, de ma már több gigabájt nagy és több ezred fájlokat. Vajon célja, hogy így működik?
A vbet_guestcache lehet jó ötlet, de ma már több gigabájt nagy és több ezred fájlokat. Vajon célja, hogy így működik?
Igen. Ez gyorsítja a teljes HTML kimenet - ahogy írva paraméter leírását. Mennyi időbe fog telni attól függ, mennyire nagy a fórum.
Felhívjuk figyelmét, hogy mindig be további figyelmen kívül hagyni oldalakat, vagy csak tiltsa le teljesen, hogy nincs lemezterület.
Persze tudtam kikapcsolni, de azt akartam, hogy csökkentsék a serverload. Talán írni az AKCS-beállításokat, hogy ez felrobbantani szerver hely, nem mindenki lehet 25 giga helyet. Vagy jobb, ha megtaláljuk a módját, hogy csökkentsék a méretét.
Nem mindenkinek szüksége van, még 1 GB erre. Mint írtam cache méretét fórum méretét. Ez gyorsítja minden lehetséges fórumon oldalt, ha nem veszi figyelembe meg. Kis fórumok kevés oldal. Nagy fórumokon több oldalas és több erőforrást.
Egyébként - ez jó ötlet, hogy az emberek jobban tudatában, mit jelent az, hogy a teljes HTML kimenet gyorsítótárba, és hozzá még információk, hogy lehet hogy sok lemezterület.
Mintegy csökkenti méret - mi adhat lehetőséget, hogy zip fájlok cache. Időbe fog telni, több szerver erőforrások cache van írva, de olvasni és küldeni, mint válasz gyorsabb lesz.
Is tudunk hozzá ütemezett feladatot, amely automatikusan eltávolítja fájlokat, amelyek túl öreg. Ebben a pillanatban nem tesszük ezt -, ha a fájl túl régi, ez egyszerűen felülírja során következő kérés.
Én elmozdítja a téma, hogy Kívánságlista![]()
Utoljára szerkesztette vBET; 27-06-10 -on 00:35.
Lenne Absolutly egyszerű:
hozzáadása lehetőséget, hogy csak a gyorsítótárból X gigabyte, majd törölje azokat, amelyek kap ritkábban látogatott.
Lol, miután telepítette az új verzió cache Soha nem néztem, hogy mennyi az a mai napig:
Debian lenny-50--64-minimal: ~ # df-h
Fájlrendszer Méret Használt Raktárkészlet Használja% szerelt
/ Dev/md2 688G 80G 573G 13% /
tmpfs 4.0G 4.0G 0 0% / lib / init / rw
udev 10M 764K 9.3M 8% / dev
tmpfs 4.0G 4.0G 0 0% / dev / shm
/ Dev/md1 2.0G 1.9G 86M 5% / boot
LOL! Mielőtt a hdd volt a használt 8GiG! Amit a "nagy", btw úgy tűnik, hogy cache hibás fájlokat, pl:
_attachment_php_attachmentid_3350.html
_blog_php.html
_blog_php_do_list_y_2009_m_10.html
I dont akar cache blogok, címkék és Mellékletek Oo
Ez is egy lehetőség. Először végrehajtja tervezett tisztább és talán cipzár (meg kell vizsgálni ezt a megközelítést), mert a vezetése statisztikák valamilyen szinten befolyásolni fogja a teljesítményt, és számunkra a teljesítmény az egyik legfontosabb kérdés. Still - fogjuk szem előtt tartani, még ez a megoldás, ha más nem lesz elég![]()
Pontosan - csak add, hogy ti nem veszi figyelembe. Egyébként köszönöm, vegye figyelembe, - adunk hozzá semmibe atachements és címkék alapértelmezett beállítás figyelmen kívül hagyja. A blogok ami sok felhasználó lehet cache-elt, tehát nem növelik azt fedault - de mi tette konfigurálható pontosan az ilyen esetekben - szeretne valami figyelmen kívül kell hagyni. Tehát ne törődj vele!![]()
Én is csak kitalálni, hogy mi is hange fájlok elnevezési sablont, és tartalmazza a fájl nevét nem tartja kevésbé releváns oldalakon, vagy sem. Így minden nap, amikor az automatikus tisztítás indul majd felismeri appropriatelly cache file time to live, és tiszta további fájlokat. Az első ötlet az volt, hogy tiszta minden, ha régebbi, mint a nem megfelelő oldalakat kell. Most tiszta érintett cache oldalak gyorsabb - így takaríthat további lemezterület!![]()