Оптимизация на кеширане на страници в BugNet
ОПТИМИЗАЦИЯ НА УЕБ СТРАНИЦА
Уеб кешът се намира между уеб сървъри (или източници) и клиент (или множество клиенти) и проверява заявки за HTML страници, изображения и файлове (общо наричани обекти) и поддържа тяхно копие. След това, когато дойде друга заявка за същия обект, тя връща съществуващото копие, без да го изисква отново от източника. Уеб кешовете се използват по две основни причини:
1. за намаляване на забавянето. Тъй като заявките се правят от кеша (разположен по-близо до клиента), а не от сървъра, където исканите обекти първоначално се намират, отнема по-малко време на клиента да извлече и покаже обекта. В резултат на това, от гледна точка на потребителя, уеб сайтът функционира по-бързо;
2. за намаляване на трафика. Тъй като всеки обект се прехвърля от сървъра само веднъж, потреблението на честотна лента на клиента се намалява. Това спестява пари, когато клиентът трябва да плати за трафик и прави възможно намаляването на изискванията за честотна лента и ги прави по-достъпни.
Уеб кеширането е една от най-неразбраните технологии в Интернет. По-специално, уеб администраторите се страхуват да не загубят контрол над своите сървъри, тъй като кешът "скрива" потребителите от тях, което затруднява виждането кой посещава сайта.
Друго притеснение е, че кешовете ще предоставят остаряло съдържание. Сървърът обаче може да бъде конфигуриран да предотврати това да се случи и все пак да улесни кеширането.
От друга страна, при правилно планиране на сървъра, кеширането може да ускори изтеглянията от вашия възел и да намали натоварването на вашия сървър и канал.Интернет. Разликата може да бъде доста значителна: зареждането от сървър, който е слабо кеширан, може да отнеме няколко секунди, докато зареждането от сървър, който се възползва от кеширането, ще бъде почти мигновено. Потребителите ценят сайтове, които се зареждат бързо и е много по-вероятно да ги посетят.
Можете да погледнете на проблема по следния начин: Много от големите интернет компании харчат милиони долари за изграждане на сървърни паркове по целия свят, за да копират съдържание, така че потребителите да имат достъп до него възможно най-бързо. Кешовете могат да направят същото за вас, дори по-близо до крайните потребители. Най-хубавото е, че дори не е нужно да плащате за тях.
Истината е, че кешовете ще бъдат използвани независимо дали ви харесва или не. Ако не се погрижите съдържанието на вашия сървър да се кешира правилно, то ще бъде кеширано според настройките по подразбиране, които администраторът на кеша смята за подходящи.
HTML мета тагове срещу HTTP заглавки
Авторите на HTML текстове могат да поставят тагове в раздел на документ, който описва неговите атрибути. Тези мета тагове често се използват с надеждата, че ще сигнализират, че даден документ не може да се кешира или че трябва да се актуализира след определен период от време.
Мета таговете са лесни за използване, но не са много ефективни. Това е така, защото те обикновено се виждат само от кешовете на браузъра (тъй като те всъщност четат HTML текста), а не от кеширащите посредници (те почти никога не анализират HTML маркирането в документи). Колкото и изкушаващо да е да поставите мета тага на началната страница"не подлежи на кеширане", това не гарантира, че потребителят ще го получи с всички последни промени, ако сървърът е достъпен чрез споделен кеш.
От друга страна, HTTP хедърите осигуряват голям контрол върху това как вашите обекти се кешират от браузъра и се обработват от посредници. Те не се появяват в HTML текст и обикновено се генерират автоматично от уеб сървъри. Все пак имате известен контрол върху тях - всичко зависи от това кой сървър използвате. HTTP заглавките се изпращат от сървъра преди HTML и са видими само за браузъра и всички междинни кешове. Типичните заглавки на HTTP 1.1 отговор изглеждат така:
HTTP/1.1 200 OK Дата: петък, 30 октомври 1998 г. 13:19:41 GMT Сървър: Apache/1.3.3 (Unix) Контрол на кеша: max-age=3600, трябва повторно валидиране Изтича: петък, 30 октомври 1998 г. 14:19:41 GMT Последна промяна: Mon, 29 Jun 1998 02:28:12 GMT ETag: “3e86-410-3596fbbc” Content-Length: 1040 Content-Type: text/html
HTML документът следва тези заглавки и е отделен от тях с празен ред.
Заглавките изтичат
Заглавката HTTP Expires е основната контрола на кеша: тя казва на кеша колко дълго даден обект може да се счита за неизтекъл; след този период кешът винаги ще проверява с източника дали документът е бил променен. Заглавките Expires се поддържат от почти всички клиенти.
Повечето уеб сървъри ви позволяват да зададете заглавки Expires, когато отговаряте по един от следните начини. Обикновено можете да посочите абсолютно време на изтичане; време в зависимост от това кога клиентът последно е видял обекта (време за последен достъп); или време в зависимост от това кога документът е бил последно модифициран (часпоследна промяна).
Заглавките Expires са най-подходящи за кеширане на статични обекти (като навигационни ленти и бутони). Тези обекти се променят рядко, така че можете да им дадете дълъг срок на валидност и в резултат на това вашият сайт ще се възприема от потребителите като по-актуален. Тези заглавки също са полезни за контролиране на кеширането на редовно актуализирани страници. Например, ако страница с новини се опреснява веднъж на ден, в 6 сутринта, тогава датата на изтичане на обекта може да бъде зададена на този час, така че самият кеш, без намесата на потребителя, да знае, че трябва да получи ново копие.
Единствената стойност в заглавката Expires, която има смисъл, е HTTP датата, всичко друго е по-вероятно да се третира като „в миналото“, т.е. че обектът не може да се кешира. Нека ви напомня, че времето в HTTP датата не е местно, а средно време по Гринуич (GMT). Например:
Изтича: петък, 30 октомври 1998 г. 14:19:41 GMT
Заглавки на Cache-Control
Въпреки цялата полезност на заглавката Expires, нейните възможности са доста ограничени. В много ситуации, когато съдържанието може да се кешира, HTTP 1.0 не може да каже на кеша какво е то и как трябва да се третира.
HTTP 1.1 въвежда нов клас заглавки, заглавките на отговора Cache-Control, които уеб издателите могат да използват, за да определят как страниците се обработват от кеша. Тези заглавки указват какво трябва да се кешира, какво може да се кешира, как трябва да се модифицира механизмът за изтичане и как да се проверява отново и зарежда.
Най-голям интерес представляват следните заглавки на Cache-Control:
max-age=[секунди] определя максималната възраст в рамкитекоито обектът не може да бъде актуализиран. Тази директива е подобна на Expires, но предоставя повече гъвкавост. Частта [seconds] на заглавката съдържа индикация за броя секунди, през които обектът се счита за неизтекъл след направата на заявката;
s-maxage=[seconds] е същото като max-age, с изключение на това, че се прилага само за споделени кешове (кеширащи посредници);
public характеризира отговора като кешируем, дори ако обикновено не е кеширан. Например, ако вашите страници изискват удостоверяване, тогава публичната директива ги прави кеширащи;
no-cache принуждава кешовете (както дистрибутора, така и браузъра) да питат източника за потвърждение всеки път, преди да предоставят копие.
Тази директива е полезна за прилагане на процедура за идентификация (в комбинация с публичния хедър) или за гарантиране, че обектът е нов, без да се губят предимствата на кеширането;
must-revalidate казва на кеша, че трябва да спазва изискванията за актуалност на обекта, които сте посочили.
HTTP дава известна свобода на кеша по отношение на актуалността на обектите; като вмъкнете тази заглавка, вие казвате на кеша, че трябва стриктно да се придържа към вашите правила;
proxy-revalidate е подобно на must-revalidate, с изключение на това, че се прилага само за кеширащи проксита.
Заглавката Cache-Control може да изглежда така:
Ако ще използвате заглавки Cache-Control, бих предложил първо да прочетете отличната чернова на HTTP 1.1 документация на http://www.w3.org/Protocols/rfc2616/rfc2616.html.
Bugnet съобщения
Lotus Notes/Домино
Microsoft Systems Management Server 2.0
В Microsoft SystemsManagement Server 2.0 Service Pack 1, минималният интервал за актуализиране за групи е фиксиран на 15 минути. Можете да зададете по-кратък интервал от време, но актуализациите пак ще се извършват на всеки 15 минути. Ако промените графика си за подновяване на членство, ще трябва да изчакате 15 минути преди първата проверка. Няма начин да се заобиколи това.