Opgegradeer na server load probleem![]()
Opgegradeer na server load probleem![]()
Is daar iemand enige idee hoe groot die lêer kas kan kry voor dit het 'n negatiewe impak op prestasie?
Databasis kas caches slegs vertalings. Nie hele HTML-inhoud. En toe sommige vertaal bladsy gegenereer is, dan die eerste normale bladsy gegenereer word en nadat dit geparseerd en vertaal. Tydens die vertaling DB kas gebruik word en vertaal sinne is van daar geneem. Net sinne - nie hele HTML, want elke keer as vertalings kan verskil (dws verskillende voorregte van die gebruikers, verander die inhoud). 'N HTML bladsy kan honderde van sinne te vertaal - vBET inhoud tussen HTML tags. Dankie DB kas daardie vertalings nie geneem word om elke keer van Google - wat baie tyd verbruik - in plaas van daardie, dit is geneem uit jou plaaslike DB. Tog - normale bladsy gegenereer word en na wat vertaal.
Volledige lêer kas vir gaste werk net vir die gaste. Dankie dat ons nie te bekommer dat gebruikers nie, het verskillende voorregte en verskillende dinge te sien. sal gaste sien dat dit dieselfde inhoud. As gevolg van wat ons het nie resultaat te parse en dit stukkie vir stukkie elke keer vertaal - ons kan dit doen net een 'n rukkie en kas vol HTML uitvoer. Dus in hierdie geval, wanneer die volle bladsy nie Cached, of Cached inhoud is te oud, dan is die normale vertaling kom - net soos beskryf voor. Maar hierdie keer by die einde volle HTML uitvoer is na 'n lêer geskryf. So, volgende keer wanneer dieselfde versoek kom van die gaste wat ons genereer nie selfs die normale inhoud van die bladsy - ons eenvoudig stroom na gas reeds Cached HTML-lêer. Dit is hoekom ons baie van SQL-navrae, SVE en geheue stoor. Ons het net gee aan die gebruiker die inhoud van die statiese lêer. Daarom is dit belangrik om te bepaal hoe lank hierdie kas sal geldig wees. Want as iets sal verander - dit wil sê 'n nuwe pos sal kom na die draad, dan gaste sal nie sien nie totdat reeds Cached lêer gedoen, hierdie nuwe pos. Daarna het tydens die volgende versoek, sal weer normaal bladsy gegenereer word, vertaal en Cached - en hierdie inhoud gaste sal dit wil sê vir nog 'n uur (configurable) sien. Hulle sal nie sien dat enige veranderinge totdat Cached lêer weer verval. Natuurlik is jou gebruikers sal sien alles, want dit werk net vir die gaste (so ook vir robots, omdat robots soek jou forum as gaste).
Asseblief vertel het dit help en in die geval van enige vrae het, vra net - ons sal graag dit beskryf meer.![]()
Dit sal word, sal ditDie meeste nuwe dinge is reeds daar getoets. Ons het net meer om te doen in die geval van Full File Cache for Guests op vB4, want ons ondersteun daar vertaling van meer soorte URL's vir vBSEO en ook vriendelike URL's van vB. En van almal wat ons het om dit baie noukeurig te toets en nog steeds ondersteuning van vroeëre herleiding vir sommige van hulle te implementeer. Ook - ons sal hierdie bykomende tyd gebruik om enige moontlike probleme met Full File Cache For Guests (wat nou as BETA beskou word) op vB3-forums na te gaan. Ons toets dit goed, maar dit is altyd beter om meer om te gee oor goeie gehalte
![]()
in die lêer / Beelde / vBET / vlae / vbet.css
Beskryf beter wat dit beteken om "weird" - miskien sal ons in staat om jou te help. Ook het ons raai om om te gebruik vir sulke dinge Firefox met plugin Firebug - dit sal jou toelaat om te wys presies wat CSS style word gebruik vir bepaalde elemente. Dit is werklik nuttig![]()
Ek weet dat daar vir almal sy weergawe is die belangriksteEn ons wil nie om te argumenteer met
In hierdie geval vBET3.x is vroeër vir 'n baie goeie rede: Kwaliteit. Ons Voeg nuwe belangrike funksionaliteit (Volledige die inhoud van die cache vir gaste) In hierdie weergawe, en dit was baie makliker om dit toe te voeg in vB3, want daar is geen Friendly URLs, en ons vertaal enigste draad URL's vir vBSEO. In die geval van vB4 is dit meer ingewikkeld - Friendly URLs moet ondersteun word, en ons vertaal veel meer soorte van URL's. Om dit die eerste keer in vB3. toegelaat dat ons dit baie goed toets op 'n ware forums, maak seker dat dit goed werk, sal miskien toon 'n paar foute voordat dit na vB4. En nadat ons volledig seker dat dit is alles goed, het ons nog by te voeg in vB4 vir ekstra ondersteuning (Friuendly URL's, meer translted URLs). Dit is waarom hierdie tyd vBET3.x is vroeër en ons moet nog 2 weke vir vBET4.x. En dankie dat jy oplossing sal kry, wat baie goeie gehalte, Ewen as dit is meer ingewikkeld Synthatin geval van vB3
Daar moet nie so iets soos negatiewe prestasie impak as gevolg van die inhoud van die cache word. Dit is omdat die inhoud van die cache nie groei ... Ons skep n aparte lêer vir elke versoek URL. So het elke kas lêer is bloot statiese HTML-lêer (Cached uitset vir die versoek). As u bediener caches meer en meer vBET skep net meer en meer lêers. En elke keer wanneer so 'n lêer gelees word:
1. Dit is slegs 'n resultaat vir hierdie spesifieke URL gelees
2. Ons lees selfs nie geheue - stroom dit net eenvoudig te kliënt met behulp van PHP funksie: readfile
As gevolg van dat selfs wanneer jou resultaat is baie groot - so kas lêer is ook groot, sal dit geen negatiewe prestasie impak het nie, want dit sal net hierdie een lêer stroom sonder selfs die lees van hele dit in die geheue. So sal jy sien voordele nie nadele.