Ostatnio wiele się o nim mówiło zalety witryn statycznych . Ale w wielu sytuacjach podejście dynamiczne jest koniecznością. Niezależnie od tego, czy jest to system zarządzania treścią, narzędzie do zarządzania relacjami z klientami czy sklep internetowy, umożliwiają one użytkownikom końcowym szybkie i spójne zarządzanie złożonymi witrynami. A kiedy są odpowiednio połączone, mogą rywalizować ze statycznymi miejscami o prędkość.
każda aplikacja, która musi często czytać i zapisywać dane, spowoduje zauważalne opóźnienie
Niezależnie od używanego systemu witryny dynamiczne zazwyczaj zawierają podobne elementy. Jest to forma serwera WWW, backendu i aplikacji napisanych w jednym lub kilku językach programowania. Ta kombinacja komponentów zapewnia dużą elastyczność, ale każda z nich przyczynia się do zwiększenia nakładu pracy i zwiększa czas ładowania, czego wszystkie nowoczesne witryny chcą uniknąć. Jest to szczególnie ważne w przypadku dostępu do bazy danych - każda aplikacja, która musi często czytać i zapisywać dane, spowoduje zauważalne opóźnienie.
To, w czym pomaga buforowanie i odpowiednia strategia buforowania dla twojego przypadku użycia. Podstawowym celem buforowania jest zapobieganie niepotrzebnym częstym połączeniom między warstwami bazy danych aplikacji, a zamiast tego korzystanie z wygenerowanych wcześniej statycznych stron HTML, które są znacznie szybsze do renderowania w przeglądarce.
Pierwszą pamięcią podręczną, jaką zauważył każdy użytkownik sieci, jest pamięć podręczna w przeglądarce. Ile razy programiści poprosili Cię o podjęcie "odświeżenia siły", aby zobaczyć zmiany? Pamięci podręczne przeglądarki są proste, ale stanowią dobry punkt wyjścia do wyjaśnienia koncepcji buforowania. Przeglądarka przechowuje reprezentacje stron internetowych odwiedzanych na komputerze użytkownika, zwykle aktualizując je raz na sesję, jeśli zmiany zostaną wykryte lub wymuszone przez witrynę.
Powszechnym narzędziem stosowanym przez właścicieli i administratorów witryny jest "pamięć podręczna odwrotnego proxy", która znajduje się między żądaniami stron utworzonymi przez przeglądarkę internetową i aplikację internetową. Przechwytuje żądania i renderuje kopie stron bezpośrednio z pamięci podręcznej, zapewniając zauważalne zwiększenie prędkości.
Dostępnych jest kilka głównych opcji pamięci podręcznej proxy do samodzielnej instalacji lub jako "Oprogramowanie jako usługa". (Ignorujemy dostawców hostingu w chmurze, którzy zazwyczaj pakują wszystko, co jest ci potrzebne, w autonomiczny stos sieciowy).
Popularne opcje pamięci podręcznej proxy obejmują:
Opcje SaaS do buforowania zazwyczaj leżą w świecie sieci dostarczania treści (CDN), które zamiast umieszczać pamięć podręczną między użytkownikiem a stosem sieci, udostępniają użytkownikom zestawy buforowanych treści, które są geograficznie najbliżej nich. To subtelna różnica, ale taka, która w przypadku dużych witryn z globalną publicznością może znacząco zmienić.
Lakier jest dostępny we wszystkich menedżerach pakietów Linux, jako obraz Docker i wiele innych opcji, przeczytaj Strona instalacji projektu po więcej szczegółów.
Varnish przechowuje domyślny plik konfiguracyjny w /usr/local/etc/varnish/default.vcl lub /etc/varnish/default.vcl , napisany w VCL (Język konfiguracji lakieru). Ten plik konfiguracyjny jest kompilowany do małego programu za pomocą interpretera C, aby zwiększyć prędkość jeszcze bardziej.
W zależności od tego, jak zainstalowałeś Varnish, plik konfiguracyjny będzie wyglądał mniej więcej tak:
backend default {.host = "127.0.0.1";.port = "8000";}W najprostszym przypadku definiuje domyślny backend używany przez Varnish, definiując host i port, na których powinien nasłuchiwać i przechwytywać treść.
Jedną z poręcznych funkcji Varnish jest sprawdzanie w określonych odstępach czasu, jeśli serwer jest nadal zdrowy. To się nazywa "Backend Polling" i jest skonfigurowane przez dodanie sekcji sond do deklaracji zaplecza:
.probe = {.url = '/';.timeout = 34ms;.interval = 1s;.window = 10;.threshold = 8;}Powyższe są domyślnymi ustawieniami zapewnianymi przez Varnish i każą odwiedzać konkretny .url co .interval, a jeśli przynajmniej .threshold z sondy .window , adres URL odpowiada w ciągu .timeout milisekund, backend jest nadal uważany za zdrowy. Kiedyś uważane jest za "niezdrowe", treść jest dostarczana z pamięci podręcznej przez wcześniej określony czas.
Omówimy konkretne zmiany w konfiguracji lakieru pod każdą opcją platformy, na razie przyjrzyjmy się ogólnym opcjom.
Porty
Początkowo port serwera WWW będzie wymagał zmiany z domyślnego. Na przykład w konfiguracji Apache Vhost zmień port na 81 lub 8080.
Uruchom demona Varnish za pomocą polecenia varnish lub używając opakowania usługi. Demon ma opcje flag, najczęstsze i najbardziej przydatne:
Sprawdzanie wszystkich działa
Uruchom komendę varnishstat lub odwiedź isvarnishworking.com aby sprawdzić, czy twój serwer Varnish jest gotowy i słucha próśb.
Czego nie można buforować
Istnieją pewne części witryny, których nie chcemy buforować, na przykład strony administracyjne. Możemy je wykluczyć, tworząc podprocedurę vcl_recv w pliku default.vcl , zawierającą instrukcję if , która określa, czego nie wolno buforować:
sub vcl_recv {# URI of admin folderif (req.url ~ "^/url/"){return (pass);}return(lookup);}Jeśli używasz Varnish 4, rzeczy są nieco inne, łącznie z wartościami zwracanymi. Funkcja vcl_recv zwraca teraz wartość ahash zamiast odnośnika.
sub vcl_recv {...return(hash);}W tym miejscu ustawiamy witryny lub subdomeny, które Varnish powinien zignorować, dodając do instrukcji if polecenie req.http.host ~ 'example.com' .
Ciasteczka
Domyślnie Varnish nie buforuje treści z backendu, który ustawia pliki cookie. Podobnie, jeśli klient wyśle plik cookie, pominie Varnish bezpośrednio na zapleczu.
Pliki cookie są często wykorzystywane przez witryny do śledzenia aktywności użytkowników i przechowywania określonych wartości użytkownika. Zasadniczo te pliki cookie są interesujące tylko dla kodu po stronie klienta i nie są interesujące dla zaplecza lub lakieru. Możemy powiedzieć Varnish, aby zignorował ciasteczka, z wyjątkiem konkretnych obszarów strony:
if ( !( req.url ~ ^/admin/) ) {unset req.http.Cookie;}Ta instrukcja if ignoruje pliki cookie, chyba że znajdujemy się w obszarze administracyjnym witryny, gdzie przekazywanie plików cookie może być bardziej użyteczne (chyba że naprawdę chcesz sfrustrować administratorów witryny).
Inne wyjątki
Przy domyślnej instalacji Varnish nie buforuje również stron chronionych hasłem, GET i HEAD.
Przyjrzymy się teraz dwóm doskonałym przypadkom użycia lakieru: Drupal i Magento. Oba są wysoce dynamicznymi systemami, które pozwalają użytkownikom nie-technicznym podejmować się różnorodnych skomplikowanych zadań. Może to prowadzić do obciążenia strony z zapytaniami do bazy danych, a ruchliwe witryny będą zauważalnie wolne. Typowe strony zbudowane przy użyciu tych systemów będą zawierać nieregularną i często mieszaną zawartość.
Drupal ma domyślne opcje buforowania, które wykonują podobne funkcje do Varnish, ale nie zapewnia elastyczności ani zwiększenia prędkości wymaganych przez większe lub bardziej złożone witryny.
W prawdziwym drupalskim stylu istnieje moduł do obsługi integracji lakierów aby zapisać niektóre opisane powyżej konfiguracje ręczne.
Zainstaluj moduł i upewnij się, że postępujesz zgodnie z instrukcjami instalacji zawartymi w pliku Read Me tego modułu.
Upewnij się, że plik / etc / default / varnish ma ustawione następujące opcje demona (a wcięcie jest ważne):
DAEMON_OPTS="-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,128M"Upewnij się, że Apache i dowolne powiązane hosty wirtualne nasłuchują na porcie 8080, a nie 80. Zrestartuj obie usługi po wprowadzeniu tych zmian.
Może być konieczne ustawienie "Klucz kontroli lakierów" na stronie konfiguracji modułu. Dowiedz się, jaki klucz znajduje się w komendzie cat / etc / varnish / secret i wklej go na stronę ustawień. Wybierz poprawną wersję lakieru, zapisz ustawienia i powinieneś zobaczyć serię zielonych tyknięć u dołu strony.
Moduł Varnish wchodzi w interakcję z domyślnymi ustawieniami pamięci podręcznej Drupala, więc upewnij się, że masz włączone i skonfigurowane dla twojego przypadku użycia.
Uruchom varnishstat z wiersza poleceń, rozpocznij nawigację po witrynie jako anonimowy użytkownik i powinieneś zobaczyć statystyki zmieniające się w wynikach polecenia.
Jedną ze ścieżek, których nie chcemy buforować w Drupalu, są strony administracyjne, możemy to zrobić z podprocedurą vcl_recv :
sub vcl_recv {# URI of admin folderif (req.url ~ "^/admin/"){return (pass);}unset req.http.Cookie;return(lookup);}Możesz rozważyć rezygnację z buforowania (logowania) stron użytkownika, stron aktualizacji systemu i innych stron generowanych przez wysoce dynamiczne moduły, takie jak flaga, które szeroko wykorzystują funkcje ajax do działania. Zrób to, dodając do parametru if dalsze parametry req.url .
Domyślna instalacja Magento jest dostarczana z wewnętrznym systemem buforowania, który przechowuje statyczne wersje elementów serwisu w określonym folderze. Strona System -> Zarządzanie pamięcią podręczną zawiera przegląd bieżącego stanu pamięci podręcznej, a także pozwala wyczyścić wszystkie lub poszczególne pamięci podręczne komponentów. Możesz usunąć zagregowane pliki CSS, JS i automatycznie generowane pliki graficzne z tej strony.
W nadchodzącej wersji 2 Magento domyślnie obsługiwane będzie buforowanie Varnish, ale na razie musimy korzystać z wtyczek innych firm, polecam Moduł terpentyny . Upewnij się, że czytasz plik readme projektu ponieważ odnotowuje pewne dodatkowe kroki konfiguracyjne, ignorowanie ich może spowodować uszkodzenie witryny.
Moduł Turpentine jest wysoce konfigurowalny i dokona niezbędnych zmian w plikach vcl i konfiguracji Varnish dla ciebie. Niektóre kluczowe opcje do ustawienia to:
Moduł Terpentine łączy się z domyślną pamięcią podręczną Magento, więc wyczyszczenie pamięci podręcznej na stronie pamięci podręcznej Varnish spowoduje usunięcie odpowiednich pamięci podręcznych Varnish.
Oprócz używania Varnish z dowolnym z powyższych dynamicznych systemów, poniżej przedstawiamy kilka innych wskazówek, które pomogą w buforowaniu dowolnej strony.
Jeśli udostępniasz tę samą treść w różnych kontekstach, użyj tego samego adresu URL. Na przykład nie mieszaj użycia artykułu.html , article.htm i artykułu , chociaż Twój CMS może na to zezwolić. Doprowadzi to do trzech różnych wersji tej samej treści z pamięci podręcznej.
Jak widzieliśmy powyżej, pliki cookie są trudne do przechowywania w pamięci podręcznej i rzadko są tak potrzebne, jak nam się wydaje. Spróbuj ograniczyć ich użycie i liczbę do dynamicznych stron.
Ładowanie zasobów witryny może być jednym z najbardziej czasochłonnych elementów renderowania strony i można tam znaleźć proste wskazówki, które zmniejszą obciążenie:
Użycie ikonek CSS Image zamiast ikon wielu małych plików powoduje mniejszy ruch w sieci.
Lokalne hostowanie bibliotek CSS i JavaScript oznacza mniejszy ruch w sieci i większą kontrolę nad strategiami buforowania. Może to oznaczać wzrost kosztów utrzymania w celu zachowania aktualności tych aktywów. Przechowuj te zasoby w spójnie nazwanych folderach, więc odniesienia do nich również mogą być spójne.
Mam nadzieję, że to wprowadzenie do przyspieszenia dynamicznych stron z buforowaniem było przydatne. Wzrost wydajności jest wart początkowego okresu konfiguracji, eksperymentowania i poprawiania. W erze krótkiej uwagi i zniecierpliwienia każde zwiększenie prędkości, które możesz wycisnąć ze swojej konfiguracji, będzie miało wpływ na twoich użytkowników i konkurencję.
Przedstawiony obraz, obraz pamięci podręcznej sieci przez Shutterstock.