Spis treści:
- Czym jest Varnish
- Przewaga pamięci RAM
- Wdrożenie Varnish z PrestaShop
- Zaawansowana konfiguracja Varnish
- Synergia Varnish i Aplikacji
- Podsumowanie
W dotychczasowej serii przeszliśmy przez kluczowe etapy przygotowań. Zaczęliśmy od diagnostyki i audytu, by nie działać na ślepo. Następnie uporządkowaliśmy fundamenty aplikacji PrestaShop – od cache, przez moduły, po aktualizacje. Zajęliśmy się optymalizacją bazy danych, konfiguracją serwera i wdrożyliśmy CDN, aby zdjąć z naszej maszyny ciężar serwowania plików statycznych.
Każdy z tych kroków był kluczowy, ale wszystkie miały jeden cel: sprawić, by aplikacja odpowiadała szybciej. Teraz wprowadzimy rozwiązanie, które sprawi, że w większości przypadków aplikacja… nie będzie musiała odpowiadać w ogóle.
Nawet najlepiej zoptymalizowany sklep e-commerce ma fundamentalne ograniczenie: każde żądanie o stronę musi zostać przetworzone. Gdy 1000 użytkowników jednocześnie wchodzi na stronę główną, Twój serwer musi:
- Uruchomić 1000 osobnych procesów PHP.
- Każdy proces musi połączyć się z bazą danych.
- Każdy proces musi wykonać dziesiątki czy nawet setki zapytań SQL.
- Na końcu aplikacja musi dynamicznie wygenerować 1000 praktycznie identycznych stron HTML.
To prowadzi do skrajnej nieefektywności i marnotrawstwa zasobów. Rozwiązaniem tego problemu jest Varnish Cache – potężne narzędzie, które działa jak warstwa buforująca dla Twojej aplikacji, pozwalając obsłużyć ekstremalny ruch bez angażowania zasobów serwera.
Efekt dla biznesu: Serwer wolny od obsługi ruchu = pełna moc obliczeniowa na koszyk i checkout = stabilna sprzedaż i brak błędów w piku.
Czym jest Varnish i dlaczego to nie jest „kolejny moduł full page cache”?
Wielu właścicieli sklepów polega na modułach full page cache. Te rozwiązania są pomocne, ale działają wewnątrz aplikacji. Oznacza to, że aby strona została dostarczona z cache’u modułu, żądanie i tak musi najpierw trafić do serwera WWW (np. Nginx), uruchomić cały silnik aplikacji (PHP), a dopiero potem moduł sprawdza dostępność wpisu w cache. To wciąż generuje niepotrzebne obciążenie.
Varnish to reverse-proxy cache. Nie jest on częścią aplikacji. To osobna, ultraszybka usługa, którą instaluje się na serwerze przed serwerem WWW. Staje się on pierwszą linią frontu, działając jako pierwszy punkt kontaktu dla przychodzących żądań.
Gdy przychodzi żądanie od użytkownika:
- Żądanie (np. o stronę kategorii) trafia najpierw do Varnish.
- Varnish sprawdza w swojej pamięci (przechowywanej bezpośrednio w pamięci RAM), czy ma już kopię tej strony.
- Jeśli tak (cache HIT): Varnish natychmiast odsyła gotową stronę HTML użytkownikowi. Proces ten trwa milisekundy. Twój serwer WWW, PHP i baza danych nie są w ogóle świadome, że to żądanie miało miejsce.
- Jeśli nie (cache MISS): Tylko przy pierwszym żądaniu Varnish przepuszcza je do serwera aplikacyjnego, czeka na wygenerowanie strony, zapisuje jej kopię u siebie w RAM i dopiero wtedy wysyła ją do użytkownika.
Dzięki temu Varnish jest w stanie samodzielnie obsłużyć 90% całego ruchu użytkowników, nie obciążając aplikacji.
Kiedy Varnish (nie) jest rozwiązaniem? Fundamenty przed wdrożeniem
Trzeba to powiedzieć jasno: Varnish nie przyspieszy wolnej aplikacji. On ją odciąży.
Jeśli Twój sklep generuje stronę kategorii w 10 sekund, wdrożenie Varnish sprawi tylko tyle, że pierwszy użytkownik (Cache MISS) poczeka 10 sekund, a kolejni dostaną tę wolno wygenerowaną stronę w milisekundach. Varnish maskuje problem, ale go nie rozwiązuje u źródła.
Dlatego wdrożenie Varnish ma sens tylko wtedy, gdy aplikacja pod spodem jest już zoptymalizowana – a o tym pisaliśmy w poprzednich artykułach. Naszym celem jest sprawienie, by ten pierwszy „strzał” (Cache MISS) był tak szybki, jak to tylko możliwe (np. poniżej 1 sekundy), a Varnish ma za zadanie chronić aplikację przed tysiącami kolejnych, identycznych żądań. Varnish nie zastępuje optymalizacji bazy danych czy fundamentów aplikacji – on na nich bazuje.
Przewaga pamięci RAM: Jak Varnish obsługuje 90% ruchu?
Aby w pełni zrozumieć różnicę, przeanalizujmy typowy scenariusz piku sprzedażowego. W ciągu jednej minuty na stronę kategorii „Promocje” wchodzi 1000 użytkowników.
Scenariusz A: Standardowy sklep (nawet z modułem FPC)
Twój serwer musi przyjąć 1000 żądań o wygenerowanie tej strony. Dla każdego z nich serwer WWW musi uruchomić proces PHP. Aplikacja startuje 1000 razy, a moduł cache wewnątrz niej sprawdza 1000 razy, czy ma zapisaną stronę (np. w pliku na dysku, w Redis lub Memcached) i 1000 razy ją odczytuje.
Rezultat: Zasoby serwera (CPU, pule procesów PHP) ulegają szybkiej saturacji. Czas odpowiedzi drastycznie rośnie, żądania trafiają do kolejki. Klienci, którzy próbują dodać coś do koszyka lub sfinalizować zamówienie, napotykają błędy lub bardzo długi czas ładowania, ponieważ serwer jest zajęty redundantnym generowaniem stron kategorii.
Scenariusz B: Sklep z Varnish
W ciągu tej samej minuty na stronę kategorii „Promocje” wchodzi 1000 użytkowników.
- Użytkownik #1: Jego żądanie trafia do Varnish. Varnish nie ma strony w cache (cache MISS). Pyta serwer aplikacyjny. Aplikacja generuje stronę (1 operacja PHP + DB), wysyła ją do Varnish. Varnish zapisuje ją w RAM i wysyła do użytkownika #1.
- Użytkownicy #2 do #1000: Ich żądania trafiają do Varnish. Varnish natychmiast odnajduje stronę w pamięci RAM (cache HIT) i odsyła ją. Wszystkie 999 żądań jest obsługiwanych bezpośrednio z RAM.
Rezultat: Twój serwer obsłużył tylko 1 pełne żądanie wygenerowania strony. Pozostałe 999 zostało obsłużonych przez Varnish. Obciążenie serwera pozostaje minimalne. Zwolnione zasoby (CPU, PHP, baza danych) mogą w pełni skupić się na tym, co najważniejsze: obsłudze koszyków, procesie składania zamówień i przyjmowaniu płatności.
Wdrożenie Varnish z PrestaShop: To nie jest „zainstaluj i zapomnij”
Rozwiązanie to jest niezwykle skuteczne, ale wdrożenie Varnish w sklepie e-commerce to zadanie wymagające precyzyjnej konfiguracji. Niepoprawne ustawienie może „zepsuć” sklep – na przykład serwując wszystkim użytkownikom widok koszyka pierwszego klienta lub cache’ując spersonalizowane ceny.
To właśnie na tym etapie kluczowa jest wiedza ekspercka i wykorzystanie zaawansowanych mechanizmów, o których standardowe wdrożenia zapominają.
Kluczowe mechanizmy: Zaawansowana konfiguracja Varnish
Aby Varnish działał poprawnie z dynamiczną treścią, potrzebuje precyzyjnych instrukcji od aplikacji. Oto cztery filary, na których opiera się profesjonalna konfiguracja Varnish PrestaShop.
Zarządzanie cache przez nagłówki (Cache-Control)
Zamiast skomplikowanych reguł VCL (Varnish Configuration Language) próbujących „odgadnąć”, co cache’ować, poprawne wdrożenie opiera się na nagłówkach HTTP wysyłanych przez aplikację. To aplikacja (poprzez dedykowany moduł) musi informować Varnish o polityce cache:
- Strona produktu/kategorii: Powinna zwracać nagłówek Cache-Control: public, s-maxage=3600, informując Varnish, by przechował ją przez godzinę.
- Strona koszyka lub konta: Musi zwracać Cache-Control: private, no-cache, co jest dla Varnish sygnałem, by nigdy nie cache’ować tej odpowiedzi i zawsze przekazywać żądanie do aplikacji.
VCL jest wciąż używany, ale głównie do normalizacji żądań i respektowania tych nagłówków, a nie do zgadywania logiki biznesowej.
Warianty cache (Nagłówek Vary)
Co jeśli ten sam URL (np. /produkt-x) ma inną cenę w zależności od waluty, grupy klienta lub jest inaczej wyświetlany na mobile i desktop? Standardowe cache zawiedzie, serwując złą wersję.
Rozwiązaniem jest nagłówek Vary. Aplikacja musi poinformować Varnish, że treść odpowiedzi jest zależna od określonych czynników (np. waluty, grupy użytkownika czy typu urządzenia). Dzięki temu Varnish wie, że musi trzymać osobne kopie (warianty) tej samej strony dla każdej unikalnej kombinacji tych czynników, pozwalając na cache’owanie spersonalizowanych widoków bez ryzyka pomieszania danych.
Inteligentne unieważnianie (Tagowanie & BAN)
Gdy administrator zmienia cenę produktu, cache musi zostać natychmiast wyczyszczony. Wysyłanie PURGE (czyszczenie) dla każdego URL z osobna jest wolne i nieefektywne.
Najlepsze podejście to tagowanie. Aplikacja „oznacza” każdą stronę nagłówkiem X-Cache-Tags, np. strona produktu dostanie tag product-123, a strona kategorii, na której on jest, tagi product-123, category-5. Gdy produkt 123 jest edytowany, moduł wysyła do Varnish jedno polecenie BAN na tag product-123. Varnish natychmiast oznacza wszystkie obiekty (strony, bloki) oznaczone tym tagiem jako wygasłe (expired). Przy następnym żądaniu o którykolwiek z tych obiektów, Varnish pobierze ich świeżą wersję z serwera aplikacyjnego.
Dynamiczne bloki i personalizacja (ESI)
Największe wyzwanie to bloki dynamiczne (np. podgląd koszyk, blok użytkownika) na stronach, które chcemy cache’ować. Rozwiązaniem jest ESI (Edge Side Includes).
Jak to działa?
- Aplikacja serwuje główną odpowiedź HTML (np. strony kategorii) ze specjalnymi „slotami” oznaczonymi tagami ESI (np. <esi:include src=”url_do_esi” />).
- Varnish cache’uje odpowiedź serwera w formie kodu HTML.
- Gdy użytkownik ją odwiedza, Varnish serwuje główny kod HTML z cache, ale jednocześnie wewnętrznie odpytuje serwer aplikacyjny o brakujące fragmenty ESI (te wskazane przez URL w tagu src).
- Najważniejsze – te fragmenty ESI również są cache’owane! Mogą mieć własne polityki Cache-Control i własne tagi. Blok koszyka może być cache’owany i unieważniany (np. przez tag powiązany z sesją klienta) tylko wtedy, gdy klient coś do niego doda, podczas gdy reszta strony pozostaje nietknięta w cache.
Synergia Varnish i Aplikacji
Jak widać, wdrożenie Varnish to nie instalacja prostej wtyczki. To synergia dwóch kluczowych elementów:
- Poprawnej implementacji Varnish przed serwerem aplikacyjnym, z poprawnie napisanym plikiem VCL, który obsługuje Vary, BAN po tagach i ESI.
- Zaawansowanego modułu po stronie aplikacji (np. PrestaShop), który inteligentnie zarządza nagłówkami Cache-Control, wysyła tagi, obsługuje ESI i komunikuje się z Varnish w celu unieważnienia cache.
Podsumowanie: Co przed nami?
Poprawne wdrożenie Varnish usuwa sufit skalowalności dla ruchu użytkowników. To krok oddzielający podejście „oby wytrzymało” od profesjonalnej, skalowalnej architektury e-commerce. Posiadanie go w swoim arsenale, jako części dojrzałej infrastruktury hostingowej (takiej jak WayBox), to już nie opcja, a konieczność dla każdego poważnego gracza na rynku.
Usunięcie tego wąskiego gardła to potężny krok, ale to jeszcze nie koniec naszej drogi. Mając tak zoptymalizowaną maszynę, w kolejnym artykule zajmiemy się ostatnimi szlifami przed szczytem. Skupimy się na tym, co jeszcze można tymczasowo wyłączyć, by zyskać cenne zasoby oraz jak zabezpieczyć sklep przed atakami DDoS.
Na sam koniec, zwieńczymy serię, przeprowadzając testy wydajnościowe. Udowodnimy „na papierze”, jak przeprowadzone zmiany wpłynęły na zdolność sklepu do obsługi ruchu, tworząc realistyczne scenariusze i porównując wyniki „przed” i „po” całej naszej optymalizacji.
