Spisu treści:
- Wprowadzenie do lakieru
- Podstawy: obrazy w pamięci podręcznej
- Standard: buforuj obrazy i strony
- Standard ++: Zwiększenie odporności serwera
- Zaawansowane użycie: Utwórz odporny serwer sieciowy w środowisku rozproszonym
- Potężne narzędzie
Jeśli chodzi o wydajność witryny, Varnish to gorąca technologia. Dzięki prostej instalacji i konfiguracji można zwiększyć wydajność dowolnej strony internetowej i obsługiwać do miliona stron za pomocą małego wirtualnego prywatnego serwera., Pokażę cztery możliwe konfiguracje, które pomogą Ci poprawić czas reakcji Twojej witryny, bez względu na to, czy obsługujesz setki, tysiące czy miliony stron.
Wprowadzenie do lakieru
Varnish-Cache to akcelerator sieciowy, którego celem jest buforowanie zawartości strony internetowej. To projekt typu open source, którego celem jest optymalizacja i przyspieszenie dostępu do stron internetowych w sposób nieinwazyjny - bez zmiany kodu - i umożliwienie włożenia rąk do witryny.
To twórcy Varnish Cache nazwali go akceleratorem sieci, ponieważ jego głównym celem jest poprawa i przyspieszenie interfejsu użytkownika witryny. Varnish osiąga to poprzez przechowywanie kopii stron obsługiwanych przez serwer WWW w swojej pamięci podręcznej. Przy następnym żądaniu tej samej strony Varnish wyświetli kopię zamiast zażądać strony z serwera WWW, co spowoduje ogromny wzrost wydajności.
Kolejną kluczową cechą Varnish Cache, oprócz wydajności, jest elastyczność języka konfiguracji, VCL. VCL umożliwia pisanie zasad dotyczących obsługi żądań przychodzących. W takich zasadach możesz zdecydować, jakie treści chcesz wyświetlać, skąd chcesz je pobrać i jak zmienić żądanie lub odpowiedź.
W poniższych przykładach konfiguracji pokażę, jakich reguł VCL należy użyć, aby osiągnąć pewne cele, od prostego buforowania obrazów i obiektów statycznych, po używanie Varnish w środowisku rozproszonym lub sprawienie, by działał jako moduł równoważenia obciążenia.
Wszystkie poniższe przykłady dotyczą lakieru 3.x. Pamiętaj, że Varnish 2.x używa innej składni i reguł, więc te przykłady nie są kompatybilne z tą wersją.
Oto główne stany Varnish, których użyjemy w pliku konfiguracyjnym VCL:
recv
Jest to pierwsza funkcja wywoływana podczas odbierania żądania. Tutaj możemy manipulować żądaniem przed sprawdzeniem, czy jest ono obecne w pamięci podręcznej. Jeśli nie można umieścić żądania w pamięci podręcznej, na tym etapie można również wybrać serwer zaplecza, na który żądanie zostanie wysłane.
przechodzić
Możemy użyć tej funkcji, gdy chcemy przekazać żądanie do serwera WWW i buforować odpowiedź.
rura
Ta funkcja omija Varnish i wysyła żądanie do serwera WWW.
wyszukiwanie
Podczas wyszukiwania Varnish prosi o sprawdzenie, czy odpowiedź jest obecna i poprawna w pamięci podręcznej.
sprowadzać
Ta funkcja jest wywoływana po wywołaniu odzyskiwania zawartości z zaplecza przez podanie lub przeoczenie.
Podstawy: obrazy w pamięci podręcznej
Spójrzmy więc na przykład konfiguracji. W tym pierwszym przykładzie po prostu buforujemy obrazy i pliki statyczne, takie jak pliki CSS. Ta konfiguracja jest naprawdę przydatna, gdy nie znasz witryny, którą chcesz ulepszyć, więc możesz po prostu zdecydować, że wszystkie obrazy, CSS i JavaScript są takie same dla wszystkich użytkowników. Aby odróżnić użytkowników, protokół HTTP wykorzystuje pliki cookie, dlatego musimy je wyeliminować w tego rodzaju żądaniach, aby wszystkie były takie same dla Varnish:
sub vcl_recv{
if(req.url ~ " * \.(png|gif|jpg|swf|css|js)"{
unset req.http.cookie;
unset req.http.Vary;
return(lookup);
}
# strip the cookie before the image is inserted into cache.
sub vcl_fetch {
if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
unset beresp.http.set-cookie;
}
I to wszystko. Za pomocą tego pliku VCL można łatwo buforować zawartość statyczną.
Standard: buforuj obrazy i strony
Zwykle nie tylko chcesz buforować statyczną zawartość swojej witryny, ale także buforować niektóre strony dynamiczne generowane przez serwer WWW, ale takie same dla wszystkich użytkowników - a przynajmniej dla wszystkich anonimowych użytkownicy. W tej fazie musisz wiedzieć, które strony mogą być buforowane, a które nie.
Dobrym przykładem jest Wordpress, jeden z najczęściej używanych systemów zarządzania treścią. Wordpress generuje strony internetowe dynamicznie za pomocą PHP i zapytania do bazy danych MySQL. Jest to miłe, ponieważ za pomocą kilku kliknięć można łatwo zaktualizować swoją stronę internetową z poziomu interfejsu administracyjnego, ale jest to również kosztowne pod względem wykorzystanych zasobów. Po co uruchamiać ten sam skrypt PHP i zapytanie MySQL za każdym razem, gdy użytkownik ląduje na stronie głównej? Możemy używać Varnish do buforowania najczęściej odwiedzanych stron i osiągania niesamowitych rezultatów.
Oto niektóre reguły, które mogą być przydatne w instalacji Wordpress:
sub vcl_recv{
# Let's make sure we aren't compressing already compressed formats.
if (req.http.Accept-Encoding) {
if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|mp3|mp4|m4v)(\?. * |)$") {
remove req.http.Accept-Encoding;
} elsif (req.http.Accept-Encoding ~ "gzip") {
set req.http.Accept-Encoding = "gzip";
} elsif (req.http.Accept-Encoding ~ "deflate") {
set req.http.Accept-Encoding = "deflate";
} else {
remove req.http.Accept-Encoding;
}
}
if (req.url ~ "^/$") {
unset req.http.cookie;
}
# Unset all cookies if not Wordpress admin - otherwise login will fail
if (!(req.url ~ "wp-(login| admin )")) {
unset req.http.cookie;
return(lookup);
}
# If you request the special pages go directly to them
if (req.url ~ "wp-(login| admin )") {
return (pipe);
}
}
sub vcl_miss {
if (!(req.url ~ "wp-(login| admin )")) {
unset req.http.cookie;
}
if (req.url ~ "^/+.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)(\?.|)$") {
unset req.http.cookie;
set req.url = regsub(req.url, "\?.$", "");
}
if (req.url ~ "^/$") {
unset req.http.cookie;
}
}
sub vcl_fetch {
if (req.url ~ "^/$") {
unset beresp.http.set-cookie;
}
# Unset all cookies if not Wordpress admin - otherwise login will fail
if (!(req.url ~ "wp-(login| admin )")) {
unset beresp.http.set-cookie;
}
}
Możesz zobaczyć, że w tym przykładzie buforujemy wszystkie strony z naszej witryny, ale dla tych, które mają w adresie URL „wp-admin” lub „wp-login”, ciągi znaków to „specjalne” lokalizacje używane do logowania się do Wordpress jako administrator. W związku z tym chcemy rozmawiać bezpośrednio z serwerem sieciowym i omijać pamięć podręczną Varnish.
Oczywiście, jeśli korzystasz z Drupal, Joomla lub niestandardowej witryny, musisz zmienić te reguły, ale cel jest zawsze ten sam: wysłać wszystkie dynamiczne strony i pamięć podręczną do zaplecza.
Standard ++: Zwiększenie odporności serwera
Czasami serwery WWW stają się wolne, ponieważ mają duże obciążenie. Lakier też może w tym pomóc. Możemy użyć specjalnych instrukcji, aby powiedzieć Varnishowi, aby unikał rozmawiania z zapleczem, jeśli jest on wyłączony lub odpowiada zbyt wolno. W takich przypadkach Lakier stosuje dyrektywę „łaski”.
Łaska w zakresie Lakierowania oznacza dostarczanie przedmiotów, które wygasłyby w inny sposób, gdy wymagają tego okoliczności. Może się to zdarzyć, ponieważ:
- Wybrany dyrektor zaplecza jest wyłączony
- Inny wątek wysłał już żądanie do zaplecza, które nie zostało jeszcze ukończone.
sub vcl_recv {
if (req.backend.healthy) {
set req.grace = 30s;
} else {
set req.grace = 1h;
}
}
sub vcl_fetch {
set beresp.grace = 1h;
}
Ta konfiguracja nakazuje Varnish przetestować zaplecze i wydłużyć okres karencji, jeśli występują jakieś problemy. Powyższy przykład wprowadza również dyrektywę „req.backend.healthy”, która służy do sprawdzania zaplecza. Jest to bardzo przydatne, gdy masz wiele zaplecza, więc spójrzmy na bardziej zaawansowany przykład.
Zaawansowane użycie: Utwórz odporny serwer sieciowy w środowisku rozproszonym
To jest nasz ostateczny plik konfiguracyjny ze wszystkimi opcjami, które widzieliśmy do tej pory i definicją dwóch tylnych końców z pewną specjalną dyrektywą dla sondy. W ten sposób Varnish określa, czy serwer sieci Web żyje, czy nie.
.url
Za pomocą tego adresu URL lakier będzie wysyłać żądania do zaplecza.
.koniec czasu
Określa szybkość zakończenia sondy. Musisz podać jednostkę czasu z liczbą, np. „0, 1 s”, „1230 ms” lub nawet „1 h”.
.interwał
Jak długo czekać między ankietami. Tutaj również musisz podać jednostkę czasu. Zauważ, że nie jest to „stawka”, ale „interwał”. Najniższy wskaźnik odpytywania to (.timeout + .interval).
.okno
Ile najnowszych ankiet należy wziąć pod uwagę przy ustalaniu, czy zaplecze jest zdrowe.
.próg
Ile ostatnich ankiet w .window musi być dobrych, aby zaplecze mogło zostać uznane za zdrowe.
Teraz możemy skorzystać z dyrektywy „req.backend.healthy” i uzyskać wynik logiczny, który mówi nam, czy zaplecze jest aktywne, czy nie.
#
# Customized VCL file for serving up a Wordpress site with multiple back-ends.
#
# Define the internal network subnet.
# These are used below to allow internal access to certain files while not
# allowing access from the public internet .
acl internal {
"10.100.0.0"/24;
}
# Define the list of our backends (web servers), they Listen on port 8080
backend web1 { .host = "10.100.0.1"; .port = "8080"; .probe = { .url = "/status.php"; .interval = 5s; .timeout = 1s; .window = 5;.threshold = 3; }}
backend web2 { .host = "10.100.0.2"; .port = "8080"; .probe = { .url = "/status.php"; .interval = 5s; .timeout = 1s; .window = 5;.threshold = 3; }}
# Define the director that determines how to distribute incoming requests.
director default_director round-robin {
{ .backend = web1; }
{ .backend = web2; }
}
# Respond to incoming requests.
sub vcl_recv {
set req.backend = default_director;
# Use anonymous, cached pages if all backends are down.
if (!req.backend.healthy) {
unset req.http.Cookie;
set req.grace = 6h;
} else {
set req.grace = 30s;
}
# Unset all cookies if not Wordpress admin - otherwise login will fail
if (!(req.url ~ "wp-(login| admin )")) {
unset req.http.cookie;
return(lookup);
}
# If you request the special pages go directly to them
if (req.url ~ "wp-(login| admin )") {
return (pipe);
}
# Always cache the following file types for all users.
if (req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?+)?$") {
unset req.http.Cookie;
}
}
# Code determining what to do when serving items from the web servers.
sub vcl_fetch {
# Don't allow static files to set cookies.
if (req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?+)?$") {
# beresp == Back-end response from the web server.
unset beresp.http.set-cookie;
}
# Allow items to be stale if needed.
set beresp.grace = 6h;
}
Potężne narzędzie
To tylko niektóre przykłady, które mogą pomóc w rozpoczęciu korzystania z lakieru. To narzędzie jest naprawdę potężne i może pomóc w osiągnięciu doskonałego wzrostu wydajności bez kupowania dodatkowego sprzętu lub maszyn wirtualnych. Dla wielu administratorów witryn jest to prawdziwa korzyść.
