Nie każdą wolną stronę da się przyspieszyć kolejną wtyczką. Czasem problem znajduje się niżej: w sposobie obsługi ruchu pomiędzy serwerem WWW, warstwą SSL, cache i samą aplikacją.

Projekt powstał jako rozszerzenie konfiguracji ISPConfig 3 dla stron opartych na WordPressie i Craft CMS. Jego zadaniem było uporządkowanie przepływu zapytań oraz dodanie warstwy Varnish Cache przed Apache.

Kontekst i problem

Bez dodatkowej warstwy cache każde żądanie może trafiać bezpośrednio do Apache, PHP, bazy danych i systemu CMS. Oznacza to, że aplikacja ponownie generuje odpowiedź nawet wtedy, gdy treść strony nie zmieniła się od poprzedniego wywołania.

Varnish pozwala przechować gotową odpowiedź w pamięci i zwrócić ją bez ponownego uruchamiania całego backendu. Zmniejsza to liczbę żądań obsługiwanych przez Apache i aplikację, ale wymaga poprawnego połączenia z HTTPS, mechanizmami czyszczenia cache oraz panelem ISPConfig.

Problemem nie było więc samo uruchomienie Varnisha. Chodziło o przygotowanie konfiguracji, która będzie przewidywalna, możliwa do aktualizowania i zgodna z istniejącym środowiskiem serwerowym.

Moja rola

Zaprojektowałem architekturę przepływu ruchu, przygotowałem konfigurację Nginxa, Varnisha i Apache oraz szablony hostów wykorzystywane przez ISPConfig 3.

Odpowiadałem również za wdrożenia serwerowe, integrację mechanizmów czyszczenia cache oraz dostosowanie konfiguracji do stron działających na WordPressie i Craft CMS.

Kod został udostępniony publicznie, aby konfigurację można było wdrażać i aktualizować bez ręcznego odtwarzania wszystkich zmian na kolejnych serwerach.

Architektura ruchu HTTPS

W przypadku ruchu HTTPS zapytanie przechodzi przez kilka oddzielnych warstw:

Internet
→ Nginx SSL Termination :443
→ Varnish Cache localhost:7443
→ Apache
→ WordPress lub Craft CMS

Nginx obsługuje połączenie HTTPS i terminację SSL. Następnie przekazuje żądanie do Varnisha, który sprawdza, czy odpowiedź może zostać zwrócona z pamięci podręcznej.

Jeżeli odpowiednia wersja strony znajduje się już w cache, Varnish zwraca ją bez uruchamiania aplikacji. Gdy odpowiedzi brakuje albo żądanie nie powinno być buforowane, ruch trafia do Apache, PHP i systemu CMS.

Dla ruchu bez SSL schemat jest krótszy:

Internet
→ Varnish Cache :80
→ Apache
→ WordPress lub Craft CMS

Każda warstwa ma jedno konkretne zadanie. Nginx obsługuje HTTPS i kompresję, Varnish pamięć podręczną, Apache aplikację, a WordPress lub Craft CMS generowanie treści.

Zakres projektu

Projekt obejmuje:

• integrację Varnish Cache z ISPConfig 3;
• konfigurację Nginxa jako warstwy SSL Termination;
• obsługę Apache jako backendu aplikacji;
• działanie ze stronami opartymi na WordPressie i Craft CMS;
• automatyczne czyszczenie cache po zmianach treści;
• integrację z WP Rocket i Proxy Cache Purge;
• współpracę z rozszerzeniem CDN Cache & Preload dla Craft CMS;
• obsługę środowisk korzystających z Cloudflare;
• kompresję Gzip i Brotli po stronie Nginxa;
• własne szablony konfiguracji hostów tworzonych przez ISPConfig 3.

Czyszczenie cache po zmianach treści

Cache przyspiesza obsługę strony tylko wtedy, gdy można go poprawnie unieważnić.

Po opublikowaniu lub edycji treści nieaktualna odpowiedź nie powinna pozostawać w Varnishu do ręcznego usunięcia. Dlatego konfiguracja została połączona z mechanizmami czyszczenia cache działającymi po stronie WordPressa i Craft CMS.

W zależności od aplikacji wykorzystywane są integracje z WP Rocket, Proxy Cache Purge albo CDN Cache & Preload. Pozwala to odświeżyć pamięć podręczną po zmianie treści bez czyszczenia całego środowiska przy każdej aktualizacji.

Dlaczego taka konfiguracja ma znaczenie

Wydajność strony nie kończy się na wyniku jednego testu. Znaczenie ma również zachowanie serwera przy większej liczbie zapytań, poprawna obsługa HTTPS, przewidywalne czyszczenie cache i możliwość dalszego rozwijania konfiguracji.

W tym projekcie Varnish nie został dodany jako odizolowana usługa. Został połączony z Nginxem, Apache, ISPConfig, aplikacją i mechanizmami aktualizacji treści.

Dzięki temu konfiguracja nie opiera się na pojedynczym ręcznym obejściu, które przestaje działać po kolejnej zmianie hosta albo aktualizacji panelu.

Testy i weryfikacja

Poprawność działania takiej konfiguracji należy sprawdzać na kilku poziomach:

• czy pierwsze żądanie trafia do backendu;
• czy kolejne żądania są zwracane z Varnish Cache;
• czy panel administracyjny i sesje użytkowników nie są buforowane;
• czy zmiana treści usuwa nieaktualną wersję z cache;
• czy HTTPS jest poprawnie obsługiwany przez Nginxa;
• czy nagłówki przekazywane pomiędzy warstwami mają oczekiwane wartości;
• czy Cloudflare nie przechowuje nieaktualnej odpowiedzi po wyczyszczeniu Varnisha.

Podstawową diagnostykę można wykonać za pomocą nagłówków HTTP:

curl -I https://example.com/

W zależności od konfiguracji warto sprawdzić między innymi:

Age
Cache-Control
Via
X-Cache
X-Cache-Hits

Dokładne nazwy nagłówków zależą od zastosowanego pliku VCL i konfiguracji Nginxa.

Ograniczenia i wymagania

Varnish nie rozwiązuje każdego problemu z wydajnością.

Jeżeli przyczyną wolnego działania są ciężkie zapytania do bazy danych, błędy PHP, zewnętrzne API albo skrypty wykonywane w przeglądarce, cache może jedynie ograniczyć część obciążenia. Nie usuwa źródła problemu.

Konfiguracja wymaga również poprawnych reguł dla treści dynamicznych, zalogowanych użytkowników, panelu administracyjnego i stron zależnych od cookies. Błędne ustawienia mogą prowadzić do wyświetlania nieaktualnej albo nieprawidłowej wersji strony.

Schemat przepływu ruchu

Opis grafiki: przepływ ruchu HTTPS w środowisku ISPConfig 3: Internet → Nginx SSL → Varnish Cache → Apache → WordPress lub Craft CMS.

Technologie

ISPConfig 3, Debian Linux, Nginx, Varnish Cache, Apache, WordPress, Craft CMS, Cloudflare, WP Rocket, Gzip i Brotli.

Repozytorium open source

Kod projektu oraz instrukcja wdrożenia są dostępne publicznie na GitHubie:

Zobacz repozytorium Varnish Cache dla ISPConfig 3

Status projektu

Projekt open source. Aktualny status utrzymania oraz obsługiwane środowiska są opisane w repozytorium.

Diagnostyka wydajności strony i serwera

Gdy problem nie kończy się na jednej wtyczce, sprawdzam cały przepływ: kod aplikacji, bazę danych, cache, integracje, PHP oraz konfigurację serwera.

Opisz obecne środowisko i sposób działania strony. Na tej podstawie można ustalić, czy wąskie gardło znajduje się w aplikacji, cache, bazie danych czy warstwie serwerowej.