Teljes verzió megtekintése: Tette vbet_guestcache a nagy
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:)
wowglider.de
05-07-10, 17:03
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.
wowglider.de
07-07-10, 09:53
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 Use% szerelt
/ Dev/md2 688G 573G 80G 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
I dont akar cache blogok, címkék és Mellékletek Oo
Felveheti őket a figyelmen kívül lehetőség. :)
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.
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:)
Felveheti őket a figyelmen kívül lehetősé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! :)
ezt a problémát orvosolni kell, hogy elvitt 4 óra, hogy megszüntesse az egészet egy quad gépen továbbá bizonyos típusú kézi flush | tiszta gombot kell adni itt, és ahelyett, hozzátéve, kézzel, mint Steve azt mondta, meg kell doboz, ahol beállíthatja egyes beállítások be-és kikapcsolása hozzáadásával pipa valami hasonló vbseo sitemap generátor beállítások nem
Automatikus vendég cache tisztább hozzá. Is hozzátette, felügyeleti eszköz vendég cache tisztításhoz. Booth része lesz vBET 3.3.5 és 4.2.3 vBET
Az ötlet, hogy ZIP fájlok cache-elt ebben a pillanatban elutasítják, mert nem minden böngésző tudja támogatni egyre ZIPed választ, és unzipping minden alkalommal fogyaszt CPU erőforrás, ami sokkal értékesebb, mint a merevlemez forrás. Abban az esetben, bármilyen ötletet ezen a területen - kérjük, nyitott az új funkciót, hogy a kérelem. Ebben ez már kevés kér, és nem képes kezelni már itt.
Kis korrekció - vBET támogatja zipping vendég cache fájlokat. Amikor vBulletin opció "GZIP HTML kimenet" be van kapcsolva, akkor vBET lesz cache már tömörített fájlt. Természetesen ebben az esetben vBET küld a megfelelő fejléceket, ha a tartalmat cache kell küldeni:)
Benne lesz a vBET 3.3.5 és 4.2.3 vBET
Michal, tegnap vBET elérte a határt a 75gb tárhely és azóta én vagyok törli az összes ~ 74 GB-os cache fájlokat.
Egy alapértelmezett telepítési ez nem elfogadható viselkedés. Kérjük, javítsa ezt a következő kiadásba.
Köszönöm.
Kérjük, vegye figyelembe, hogy nincs hiba, így nincs mit javítani. Ha nagy fórum és beállított vBET teljesen cache azt 52 különböző nyelven. Ez az, amit vBET készül. vBET nem támogatják a cache külső források, és az ilyen dolog, nem lenne értelme, mert a küldés és a szerzés vissza lenne drágább, mint a normál generációs oldalon. Így kell használni a saját források file cache.
Kérjük, vegye figyelembe, hogy beállítható, hogy figyelmen kívül hagyja további oldalak Vendég gyorsítótár a figyelmen kívül hagyása a teljes fájl cache számára, vagy csak kapcsolja ki teljesen, ha a szerver nem elég erőforrás, hogy használja ezt a funkciót. Alapértelmezés szerint vBET figyelmen kívül hagyja ezeket az oldalakat: regisztrálj, keresés, bejelentkezés, lefoglalás, címkék.
Adhatunk még néhány oldalt figyelmen kívül hagyja - a nem cache, így azok nem tárolja a fájlokat és a generál általában minden alkalommal, hogy nagyobb a CPU és a memória erőforrásait. Ez valamit valamiért. A teljesítmény-megtakarítás származik tárolását eredményezi statikus fájlokat, és ha kell hely, hogy vagy a dallam Vendég gyorsítótár fel (figyelmen kívül hagyva több típusú oldal).
Nyitottak vagyunk a javaslatokat. Ha bármilyen javaslata, hogyan lehetne javítani vBET Vendég cache funkciót, akkor szívesen tartja, és javítja, ha lesz elfogadható:)
Is - ha úgy találja, hogy az automatikus cache tisztább nem működnek a cache fájlok - kérjük, vegye figyelembe, hogy a hiba.
Automatic Translations (Powered by Google, Microsoft®,
Yandex, SDL Language Cloud, IBM Watson and Apertium):
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.