кеширане Automation

Кеширане на ниво клиент и сървър може значително да се ускори скоростта на сайта. В момента всички съвременната система за управление на съдържанието включва подкрепа за кеширане, в някои случаи и на много нива.

Кеширане на ниво клиент

Създаване на кеша за да се избегнат допълнителни искания от браузъра към сървъра е достатъчно проста: трябва само да се запознаят с най-типичните случаи употреба:

Статичните ресурси некомпресиран

Принуждават кеширане за статични ресурси, без компресия. В този случай, ние рискуваме нищо, излагайки не само максималното време за кеширане, но също така предлага на кеш ресурси на местно прокси (директива Cache-Control: публична). За PHP, ние ще имаме следния код (в Expires дата разписани в следващите 10 години, в сравнение с текущото време на сървъра):

В случая с даването на указания за Apache:

И в случай на Nginx:

10-годишният кеширане живот тук е напълно оправдано: за да можем да информира потребителите, че ресурсите не се нуждаят от perezaprashivat през това време. Ако ресурси са се променили, ние все още ще има кеш за ускоряване на облекчение (повече за това по-долу), за да се гарантира правилното показване на материали от сайта във всички браузъри.

Статичните ресурси с компресия

Очевидно е, че в някои случаи и на директивата може да се комбинира с предишния случай.

Ако трябва да добавим кеширане за определен срок за HTML-документи, които предписват достатъчно файлови разширения Директива FilesMatch, изброени по-долу.

Бан кеширане динамични ресурси

Обикновено, за произволно място (информация, на която се променя често) кеширане HTML-документи е забранено. Това се дължи на бързо остаряване на информацията (заслужава да се отбележи, че правилата за показване на информация и взаимодействие стилове и скриптове остарели много по-бавно, отколкото на информацията).

За да забраните кеширането за всички браузъри, HTML-документи, които трябва да се пишат с помощта на PHP (в Изтича написани на текущото време на сървъра):

Reset кеш

Доста често чрез кеширане на нивото клиент, отказват се дължи на факта, че понякога е трудно да се осъществява контрол върху поведението на всички браузъри, в случай на частична или пълна промяна на ресурсите, които са в кеш паметта.

низ на заявката

В действителност, този проблем се струва съвсем проста, и в книгата "Overclocking сайта си" е дадена редица начини за предоставяне на този механизъм. Най-лесният начин е, че ние можем да добавите специален GET-параметър (или просто низа на заявката), за да ни ресурс. В този случай, промените URL на браузъра (но за сървъра остава същото), че всъщност решава проблема.

Да разгледаме следния разговор CSS-файл:

Ако използваме клеймото и ние имаме, да речем, името на файла, който искаме да включим в документ като лист със стилове, следната PHP-кодът предоставя уникална кеширане за нашия случай:

Името на физически файл

Горното решение е една малка недостатък: Някои прокси сървъри няма да кешират файлове с низа на заявката, включително и тяхната динамика. Ние можем да се справите с тази ситуация, като Rewrite-правило в конфигурацията на Apache:

Какво като то означава? И този, който, когато се посочва в HTML-документ връзка към файл

сървърът ще върне физическата файл

Така че ние елегантно заобикаля проблема с прокси сървъри на един ред в конфигурацията на сървъра. Съответният PHP-код ще изглежда така:

Създаване на хашиш

Както вече бе споменато по-горе, за да автоматизирате процеса на възстановяване на кеш паметта на клиента всеки път, когато трябва да зададем за файловата система за файлови промени. Ако файловете имат множество, допълнително натоварване увеличава многократно. Но като се има предвид факта, че ние ще всички да бъдат комбинирани в един файл, ние можем да по някакъв начин да контролира промяната на изходния файл, без да провери, докато всички принадлежащи към него.

Нека да разгледаме примера, даден в началото на главата. Ние можем да се съберат всички известни случаи на файлове в документ, в един ред, а след това се изчисли хеш на получения низ:

Така че ние ще актуализираме кеш клиент всеки път, когато се промени най-малко един разговор от файловете, които формират хеш. Това не решава проблема, поставен в началото на главата (ние все още трябва да се провери самия файл, в който малцина, да се промени датата комбиниран), но помага за решаване на подобен проблем, който възниква в хода на общи решения за голям проект.

Използване на споделена памет

Всъщност решението на физически проблеми File Checker да се промени на повърхността. За да направите това, вие трябва да ни предоставите:

Свързани споделени библиотеки памет (APC, eAccelerator, кеша в паметта).
Способността да се управлява състоянието на кеша (и редактирането на сканираните файлове през уеб интерфейса, частично изчисти кеша или твърд проучване кеширани файлове).

В примера, описан АРС алгоритъм е както следва:

Както може да се види, предложеният алгоритъм е съвсем проста (и може да бъде намален до една проста процедура за почистване на кеша, когато сме създали за всички комбинирани файлове ние принуди възстановяване), но напълно се избягва споменаването на файловата система (или кеш), когато действието на страница за оптимизация на клиента.

Така кеширане на нивото клиент, може да ускори зареждането на следващите страници (или посещения) към вашия сайт с 80-90% (5-10 пъти), както и правилното управление на кеширане ви уверява, че информацията, получена от потребителя, винаги ще бъде от значение.

Кеширане на ниво сървър

Доста често виждаме ситуация, в която създаването на страници на сървъра, отнема няколко (десетки) секунди. Анализ на обичайните причини за това и възможни решения на такава ситуация, няма да бъдат разглеждани (тя надхвърля настоящата книга), но има и някои методи за облекчаване на проблемите на "бавни" страници. Става дума за най-простите кеширане създаден HTML-документи.

Обикновено (в случай на динамични сайтове) за създаване на HTML-страници са десетки или стотици заявки към базата данни са свързани десетки (или стотици) различни библиотеки, и не винаги може да правилно се справят с проблемите на броя на заявките на ниво база данни или ускорител съставянето изпълним код (например, eaccelerator).

На общо Хостинг (когато ресурсите на един сървър могат да споделят десетки или стотици различни сайтове) с относително прост сайт (които не предполагат значително взаимодействие с потребителя), струва си да се обмисли възможността за създаване на кеш готови HTML-страници. Какво е това?

Връщаме кеширана документа

Всеки конкретен потребител по искане към сървъра се готви HTML-документ, който включва само на клиента (което е независимо от състоянието на сървъра) динамика, която работи в браузъра на потребителя (и се съхранява в кеш), но не и на сървъра. Съответно, ние всъщност може да се симулира една и съща кеша на браузъра само ресурсите на сървъра.

За по-подробен пример, нека разгледаме следния код, отговарящ на най-простият от страна на сървъра кеширането на Web Optimizer:

променлива $ cache_me може да се формира на базата на множество параметри (включително част от URL, което е необходимо или не да се кешират, потребителски агенти и роботи, за които можем да дадем на кеширани версии на страниците и т.н.). Трябва също да се отбележи, че само създадете файл с име, е равна на текущата URL адреса на страницата, не е възможно: Намерих го невалидни знаци (/.), която трябва да се преобразува ще се запише в файлова система.

Създаване кеширана документ

Но ние погледна процеса на издаване на кеширано документ, и как тя се появява на вашия твърд диск? Процедура за съхранение на файла е малко по-лесно, и може да се запише по следния начин (кода на уеб Optimizer):

сървърни ресурси (като се използва не електроразпределение) трябва да бъде конфигуриран кеширането на ниво сървър е в състояние да спести време на посетителите си (и по този начин да се повиши превръщането на сайта) и спаси.

кеширане Automation