Обновен след проблем на натоварване на сървъра![]()
Обновен след проблем на натоварване на сървъра![]()
Дали някой има някаква идея, колко голям кеш файл може да получи, преди това има отрицателно въздействие върху производителността?
Database кеш кешира само преводи. Не е цялата HTML съдържание. Така че, когато някои преведена страница се генерира, тогава първо нормална страница се генерира и след това се прави разбор и преведени. По време на превод DB на кеша се използва и преведени изречения са взети от там. Просто изречения - не цели HTML, защото всеки път, преводи могат да бъдат различни (т.е. различни привилегии на потребители, променено съдържание). Един HTML страница може да има стотици изречения, за да превежда - vBET се съдържание между HTML таговете. Благодарение DB кеш тези преводи не трябва да се вземат всеки път от Google - какво консумира много време - вместо това, те са взети от местните DB. И все пак - нормален страница трябва да бъдат генерирани и след това преведен.
Пълен кеш файл за гости работи само за гостите. Благодарение, че ние не трябва да се притесняват, че потребителите имат различни привилегии и да видите различни неща. Ще гостите видите същото съдържание. Поради това ние не трябва да прави разбор на резултат и превежда парче по парче, всеки път - ние можем просто да го направя докато и кеш пълна мощност HTML. Така че в този случай, когато цяла страница не се кешира, или кеширана съдържание е твърде стар, а след това нормалната превод се случва - точно както е описано преди. Но този път в самия край, пълен HTML изход е написан на файла. Така че следващия път, когато същото искане идва от гостите не генерира дори нормално съдържание на страницата - ние просто поток гост вече кеширани HTML файл. Ето защо ние спаси много SQL заявки, процесора и паметта. Ние току-що даде на потребителско съдържание от статично файл. Ето защо е важно да се определи колко дълго този кеш ще бъдат валидни. Защото, ако нещо ще се промени - т.е. нова публикация ще се стигне до конец, а след това гостите не ще видите тази нова длъжност до изтичането на вече кеширани файл. След това по време на следващото искане, отново нормална страница ще бъдат генерирани, преведени и Кеширана - и това съдържание гостите ще видят, т.е. за още един час (конфигурируеми). Те няма да видите никакви промени, докато изтече кеширана файла отново. Разбира се, потребителите ще виждат всичко, защото тя работи само за гостите (така за роботи, защото роботите да обходим форум като гости).
Моля, кажете на помощ и в случай на някакви въпроси, просто попитайте - ние с удоволствие ще го опиша повече![]()
Тя ще бъде, тя ще бъдеПовечето нови неща вече са тествани там. Ние просто имаме още какво да правим в случай на Full File Cache за Гости на vB4, защото ние подкрепяме там превод на повече видове URL адреси за vBSEO и също Приятелски URL адреси от vB. И от всички тези, които трябва да го тестваме много внимателно и все още трябва да внедрим подкрепа на по-ранно пренасочване за някои от тези. Също така - ще използваме това допълнително време, за да проверим всички възможни проблеми с Full File Cache For Guests (който се счита за БЕТА сега) на форумите на VB3. Тестваме го добре, но винаги е по-добре да се грижим повече за доброто качество
![]()
във файл /images/vBET/Flags/vBET.CSS
Моля, опишете по-добре какво означава "странни" - може би ще може да ви помогне. Също така ние препоръчваме да се използва за такива неща Firefox с плъгин Firebug - това ще позволи да ви покажа, кои точно CSS стилове се използват за точно определени елементи. То е наистина полезно![]()
Знам, че за всеки му версия е най-важноИ ние не искаме да споря с това
В този случай vBET3.x е рано за много добра причина: КАЧЕСТВО. Ние добавяме нови важни функции (Пълен кеш файл за гости) в тази версия и е много по-лесно да го добавите в vB3, защото няма приятелски URL адреси, и превежда само нишка URL адреси за обяви. В случай на vB4 е по-сложно - приятелски URL адреси трябва да бъдат подкрепени, и превежда много повече видове на URL адреси. Поставяйки я първо в vB3. ни позволи да го тествам много добре на реални форуми, проверете, че тя работи добре, може би ще покаже някои бъгове преди това отидете vB4. И след като ние сме напълно сигурни, че това всичко е наред, ние все още трябва да добавите в vB4 допълнително поддръжка (Friuendly URL адреси, повече translted URL адреси). Това е защо този път vBET3.x е по-рано и ние все още трябва 2 седмици за vBET4.x. И благодаря, че вие ще получите решение, което има много добро качество, ewen, ако тя е по-сложно thatin случай на vB3
Не трябва да има такова нещо като отрицателни резултати въздействие, тъй като на кеш файл. Това е, защото кеш файл не расте ... Ние създаваме отделен файл за всяка заявка URL. Така че всеки кеш файл е просто статичен HTML файл (кеширани изход за поискване). Когато вашият сървър кешира повече и повече vBET, просто създава повече и повече файлове. Така че всеки път, когато се чете такъв файл:
1. Тя е само за четене резултат за този конкретен URL
2. Ние дори не я прочетете в паметта - просто го поток на клиента, използва PHP функция: readfile
Поради това, дори, ако вашата резултат страница е наистина голям - така че кеш файл е голям, той ще нямат отрицателно влияние за изпълнение, защото тя просто ще поток този файл, без дори четене цяло, тя в паметта. Така вие ще видите предимства не недостатъци.