Pamiętacie mój niedawny wpis o tajemniczym ulepszeniu?
Na tym blogu kwestie techniczne WordPressa pojawiają się rzadko. Dziś zobaczymy sobie raz jeszcze w jaki sposób spowodować, żeby nasz blog zaczął kicać trochę żwawiej niż dotychczas. Tym razem z nieco innego kąta.
Zaczniemy od jednego, bardzo podstawowego pytania: czy nasz blog działa za wolno?
- "Nasz"? To my mamy wspólny blog?
Nie 😉 Tak się tylko mówi. No dobrze, jeszcze raz: czy Twój blog działa za wolno?
- A co to w ogóle znaczy: "za wolno"?
Podpowiem: jeżeli na otwarcie strony głównej / którejkolwiek z podstron trzeba czekać dłużej niż 2 sekundy, to to jest za wolno. Człowiek po dwóch sekundach czekania zaczyna się poważnie zastanawiać, czy nie opuścić naszej strony, a po trzech - czterech prawie na pewno ją opuści.
Blog xpil.eu ma długą historię optymalizacji (lub - częściej - jej braku). Bywało lepiej, bywało gorzej. Ogólnie jest nieźle, acz zdarzyło mi się kiedyś trzymać blog na serwerze w Stanach, co było prawdopodobnie najgorszą decyzją od czasu kiedy zacząłem się uczyć programowania komputerów za pomocą żółwia z pisakiem w dupie[1].
Drugie pytanie brzmi: jak bardzo "dynamiczny" jest nasz blog? Jak często zmieniają się na nim informacje? Czy mamy jakieś widgety, które powinny wyświetlać coś innego przy każdym otwarciu strony? I tak dalej.
- Dlaczego to jest takie ważne?
Ponieważ w zależności od tego, czy chcemy mieć stronę "dynamiczną" czy nie, wybierzemy strategię buforowania blogu.
- Bufo-co?
No, mówię przecież wyraźnie: cache. Bufor. Pamięć podręczna znaczy się.
PHP (w którym jest napisany WordPress) ma dwa główne sposoby buforowania informacji: page-cache oraz object-cache.
Page-cache jest "głupi", po prostu zapamiętuje całą zawartość strony "jak leci" według adresu w pasku przeglądarki i jeżeli taki sam adres pojawi się po raz drugi, użytkownik dostanie tę samą kopię strony co ostatnio, bez konieczności odpytywania serwera bazy danych, uruchamiania całego kodu PHP WordPressa na naszym blogu i tak dalej.
Efekt: strona otwiera się "momentalnie", czas odpowiedzi serwera www jest bliski zeru, jedyne na co czekamy to przepchanie treści przez łącza sieciowe między serwerem www a naszą przeglądarką. Zawartość strony będzie identyczna z tą, którą widzieliśmy poprzednio pod tym adresem.
Ta metoda działa bardzo fajnie jeżeli nie zależy nam na dynamicznej treści blogu.
- A co, jeżeli nam zależy?
Wtedy można albo "nauczyć" metodę page-cache rozpoznawania faktu, że strona się zmieniła (niektóre wtyczki do WordPress robią to całkiem sprawnie), albo zamiast page-cache sięgamy po object-cache, czyli metodę polegającą na zbuforowaniu wszystkich obiektów na naszej stronie pod zadanym adresem w taki sposób, żeby przy kolejnym otwarciu tej strony elementy "statyczne" były zaserwowane przeglądarce "od razu", a elementy dynamiczne - niech się wygenerują po stronie serwera jak pambuk przykazał i dopiero wtedy hyc do przeglądarki.
Zaleta: losowe cytaty, liczniki odwiedzin i inne tego typu duperele będą wyświetlane poprawnie i na bieżąco.
Wada: działa ciut wolniej, bo jednak "coś" po stronie serwera musi najpierw stwierdzić, które elementy są statyczne, które dynamiczne, które można odsyłać klientowi od razu, a na które trzeba poczekać itd.
Osobiście wolę tę drugą metodę, bo chociaż jest nieco wolniejsza od pierwszej, to różnica w szybkości jest niewielka, a nie musimy poświęcać żadnej funkcjonalności. No i jest bardziej "elegancka" - w przypadku bowiem metody page-cache odświeżyć trzeba CAŁĄ zawartość strony, a przy object-cache tylko te jej elementy, które uległy zmianie.
No i teraz pozostaje nieśmiertelne pytanie: jak to zrobić?
- Jak to zrobić?
Bardzo dobrze, że pytasz! Odpowiedzi jest mnóstwo i niektóre z nich już tu kiedyś prezentowałem. Mówiłem o różnych wtyczkach cache-ujących, mówiłem o aplikacji memcached, mówiłem o minimalizacji i kompresji kodu JS/CSS, przeglądaniu i wyrzucaniu zbędnych wtyczek do WordPressa, optymalizacji obrazków...
- Do rzeczy, człowieku!
OK, ok 😉 Odpowiedzią jest: REDIS. Redis to cudo, które odkryłem kilka dni temu i od razu polubiłem.
- Dlaczego?
Bo jest prosty, szybki i bezawaryjny.
- Cóż to takiego, ten cały rebis?
Nie rebis tylko Redis. "Redis" to skrót od "REmote DIctionary Server" czyli po naszemu "ZDalny Serwer SŁownikowy", czyli w skrócie ZDSSŁ. Najkrócej mówiąc jest to "prościutka" baza danych typu klucz-wartość, a więc należy do tej samej rodziny co Cassandra, HBase czy Couchbase. Jej główną zaletą jest to, że wszelkie operacje na danych odbywają się wyłącznie w pamięci RAM. Przy starcie systemu Redis ładuje sobie bazy danych z dysków do pamięci, potem od czasu do czasu zapisuje dane na dyski (w osobnym wątku, żeby nie przeszkadzać), a wszystko inne odbywa się wyłącznie w RAM-ie. To sprawia, że Redis jest cholernie szybki. Wąskim gardłem przeważnie okazuje się sieć albo ilość pamięci RAM, nigdy CPU. Dodatkowo Redis ma opcję pracy w trybie cache, w którym to trybie zamiast kucnąć po zapełnieniu dostępnej pamięci danymi, po prostu usuwa najstarsze / najmniej używane dane i działa dalej.
Ten właśnie tryb (cache) przydaje się do współpracy z WordPress-em.
Wtyczek WordPress obsługujących cache-owanie za pomocą Redis jest kilka i wszystkie działają (jedne lepiej, inne gorzej). Użytkowników bardziej "hardcorowych" zachęcam do poeksperymentowania i wdrożenia systemu "bezwtyczkowego" (tak naprawdę jest to kwestia zainstalowania i uruchomienia serwera Redis, a potem dorzucenia jednego pliku php do głównego folderu WordPress-a - i to wszystko).
Może kiedyś zachce mi się napisać bardziej szczegółową instrukcję instalacji / konfiguracji tego cudaka na własnym serwerze. Póki co tylko wskazuję kierunki: kierunek 1, kierunek 2, kierunek 3
Powodzenia.
Read in English: EN
[1] Gwoli wyjaśnienia: nie miałem w dupie żółwia z pisakiem, to żółw miał pisak w dupie, a ja się na jego przykładzie uczyłem programowania komputerów. Oraz, jak sądzę, miłości do zwierząt...
A co z innym wytczkami do keszowania stron, które są polecane do instalacji na WP? niekoniecznie mowa o REDIS ale np. wp total cache ?
To są w większości dobre, fajne wtyczki. Osobiście od kilku lat używałem CometCache Pro, ale przedtem również Total Cache, W3TC (w czasach kiedy jeszcze nie próbowali wpychać na siłę wersji płatnej) i paru innych. Tylko że każda z nich ma jakieś tam drobne minusy, no i przede wszystkim każda wymaga (uwaga, szok!) zainstalowania w formie wtyczki w lokalnej instalacii Wordpres-a. A Redis działa o jeden level niżej, nie masz żadnej wtyczki cache w samym WordPressie, wszystko odbywa się niejako “samo” na poziomie OS, na zasadzie fire-and-forget. No i masz GWARANCJĘ, że wszystko będzie cache-owane w pamięci RAM a nie na dysku, bo tak działa REDIS.
Ło, panie, a kto panu tak stronę spi… zmienił?
Sam sobie spi… zmieniłem 🙂 Póki co jestem na etapie eksperymentowania, proszę o wyrozumiałość…
A już myślałem, że jakiś virus experatimus Ci namieszał 😉
Wirus wirusem, na Linuksie o wirusy raczej ciężko. Natomiast muszę przyznać, że spamerzy się robią coraz bardziej wyrafinowani. Od kilku dni mam atak polskojęzycznego spamu, który nie dość, że się jakoś przeciska przez sito Akismet, to jeszcze brzmi na pierwszy rzut oka na tyle wiarygodnie, że prawie się dałem nabrać. Apage!