Spojrzenie na nowoczesny stos serwerów WordPress

Czy pamiętasz, kiedy można było uruchomić „szybką” witrynę WordPress z samym serwerem Apache i PHP? Tak, to były czasy! Wtedy sprawy były o wiele mniej skomplikowane.

Teraz wszystko musi ładować się błyskawicznie! Odwiedzający nie mają takich samych oczekiwań co do czasów ładowania, jak kiedyś. Powolna strona internetowa może mieć poważne konsekwencje dla Ciebie lub Twojego klienta.

Dalsze czytanie na SmashingMag:

• Właściwe uprawnienia i prawa własności systemu plików WordPress
• Przenoszenie witryny WordPress bez kłopotów
• Jak rozwijać WordPress lokalnie za pomocą MAMP
• Zrób to sam metody buforowania za pomocą WordPress

W związku z tym stos serwerów WordPress musiał ewoluować przez lata , aby nadążyć za potrzebą szybkości. W ramach tej ewolucji do silnika trzeba było dodać kilka biegów. Niektóre starsze biegi również musiały się zmienić.

W rezultacie stos serwerów WordPress wygląda dziś zupełnie inaczej niż kilka lat temu. Aby lepiej to zrozumieć, szczegółowo przyjrzymy się temu nowemu stosowi. Zobaczysz, jak różne elementy pasują do siebie, aby witryna WordPress była szybka.

Przegląd

Zanim zagłębimy się w temat, pomniejszmy i spójrzmy na duży obraz. Jak wygląda ten nowy stos serwerów WordPress? Cóż, oto odpowiedź:

Powyższy diagram daje dobry przegląd tego, jak wygląda współczesny stos serwerów WordPress. Na wysokim poziomie możemy podzielić to, co się dzieje na trzy obszary:

• cykl żądanie-odpowiedź między przeglądarką a WordPress;
• WordPress (który jest skryptem wykonywanym przez środowisko wykonawcze PHP);
• cykl zapytanie-wynik między WordPressem a bazą danych MySQL.

Rolą nowoczesnego stosu serwerów WordPress jest optymalizacja tych trzech obszarów. Te optymalizacje sprawiają, że wszystko ładuje się szybciej. A najlepsze jest to, że można to zrobić na kilka sposobów. (Tak!)

W większości przypadków te optymalizacje obejmują instalowanie nowych usług na serwerze. Czasami usługi te będą wymagały pomocy wtyczki do interakcji z WordPress. Zdarzają się również sytuacje, w których wystarczy zainstalować wtyczkę. W tym artykule zobaczysz wiele różnych opcji.

Cykl żądanie-odpowiedź

Wszystko zaczyna się od przeglądarki. Załóżmy, że chcesz wyświetlić stronę modern.wordpress-stack.org . Twoja przeglądarka uruchomi się od wysłania żądania HTTP do serwera WWW, który ją obsługuje. Z drugiej strony serwer WWW przejmie żądanie i zamieni je w odpowiedź HTTP.

Ta pierwsza odpowiedź powinna zawsze być zawartością HTML strony głównej modern.wordpress-stack.org (chyba że wystąpił błąd). Jednak praca Twojej przeglądarki nie jest skończona. Nie, ta strona główna nadal potrzebuje więcej plików, z których najczęstsze to pliki CSS, JavaScript i obrazy.

Tak więc przeglądarka wyśle ​​​​prośby o te pliki. Serwer sieciowy odpowie żądanymi plikami (ponownie, o ile nie ma błędów). Ten cykl będzie kontynuowany, dopóki przeglądarka nie będzie miała wystarczających informacji, aby wyrenderować stronę główną. Im szybciej przebiega ten cykl, tym szybciej strona będzie się ładować.

To oczywiste uproszczenie, ale tak właśnie działa większość witryn WordPress.

Optymalizacja cyklu żądanie-odpowiedź

W porządku, to prowadzi nas do oczywistego pytania: Jak sprawić, by serwer WWW wykonywał ten cykl szybciej? To świetne pytanie i jest jednym z powodów, dla których istnieje nowoczesny stos serwerów WordPress.

Stos istnieje, ponieważ nie można po prostu przyspieszyć serwera WWW. Serwer WWW jest również dyspozytorem. Może odebrać żądanie i po prostu przekazać je do innych usług.

Te inne usługi są często wąskim gardłem tego cyklu żądanie-odpowiedź. W przypadku WordPressa tym wąskim gardłem jest PHP, dlatego optymalizacja cyklu żądanie-odpowiedź sprowadza się do dwóch rzeczy. Chcemy, aby serwer WWW:

• otrzymuj jak najmniej próśb,
• prześlij jak najmniej żądań do PHP.

Nowoczesny stos serwerów WordPress koncentruje się na tym ostatnim. Chce przekazać jak najmniej żądań do PHP. To będzie główny cel optymalizacji stosu.

Skupiamy się na drugim celu, ponieważ stack nie może wiele zrobić z pierwszym; nie ma na to bezpośredniego wpływu. Drugim rozwiązaniem jest konfiguracja serwera WWW lub nowoczesne techniki programistyczne.

Układaj elementy dla cyklu żądanie-odpowiedź

Więc jakie są elementy stosu, które pomogą nam zredukować żądania przekazywane do PHP? Cóż, w osiągnięciu tego celu pomogą nam w szczególności dwa elementy stosu: serwer WWW i pamięć podręczna HTTP.

Serwer internetowy

Mówiliśmy już sporo o serwerach internetowych. W przestrzeni serwera WWW jest trzech dużych graczy:

• Apache
• Internetowe usługi informacyjne (IIS)
• nginx

Razem stanowią one ponad 90% udziału w rynku serwerów WWW w Internecie. Skoncentrujemy się na Apache i nginx. Chociaż IIS może być używany do uruchamiania WordPressa, nie jest to powszechne, ponieważ jest dostępny tylko dla systemu Windows, a większość serwerów WordPress korzysta z systemu Linux.

Pozostaje nam Apache i nginx. Przez całe życie WordPressa Apache był zalecanym serwerem WWW. Mieliśmy stos LAMP (Linux, Apache, MySQL i PHP), który uruchamiał WordPressa zarówno na komputerze, jak i na serwerze.

Ale za kulisami wszystko się zmieniało. W mieście pojawił się nowy gracz i nazywał się nginx. Automattic i WordPress.com używają go od 2008 roku. Jest to serwer sieciowy, który obsługuje największy odsetek witryn o dużym ruchu (z których wiele korzysta z WordPressa). Dlatego wiele wysokiej klasy firm hostingowych i najlepszych agencji WordPress używa go jako swojego serwera internetowego.

Nie chodzi o to, że Apache jest złym serwerem WWW. Są eksperci Apache, którzy potrafią sprawić, że będzie działał świetnie w dużym natężeniu ruchu. Po prostu nie działa tak dobrze po wyjęciu z pudełka lub ze standardową konfiguracją WordPress.

Tymczasem jedynym celem nginx jest obsługa dużego ruchu. Dlatego Igor Sysoev rozpoczął projekt, gdy pracował w Rambler.

Jednym z powodów, dla których nginx lepiej radzi sobie z większym ruchem, jest to, że używa FastCGI do komunikacji z PHP. Co to jest FastCGI? Jest to protokół, który pozwala PHP działać jako usługa oddzielona od serwera WWW.

Apache nie robi tego domyślnie. Za każdym razem, gdy serwer WWW otrzymuje żądanie, musi uruchomić proces wykonawczy PHP — nawet dla obrazów, JavaScript i CSS. Zmniejsza to liczbę żądań, które serwer może obsłużyć i jak szybko może je obsłużyć.

Jest to sprzeczne z jednym z celów współczesnego stosu serwerów WordPress, który widzieliśmy wcześniej. Stos musi utrzymywać jak najkrótszy czas cyklu żądanie-odpowiedź. Ładowanie PHP dla każdego żądania, nawet jeśli go nie potrzebuje, jest sprzeczne z tym celem. Tak więc, jeśli używasz Apache, spójrz na FastCGI.

HTTP/2 to kolejna ważna funkcja serwera WWW, o której powinieneś wiedzieć. To kolejna wersja protokołu HTTP, który obsługuje cały nasz cykl żądanie-odpowiedź.

Przed nadejściem HTTP/2 przeglądarka mogła mieć tylko sześć połączeń z serwerem WWW. Każde połączenie mogło obsłużyć tylko jedno żądanie na raz. Tak więc w praktyce cykl żądanie-odpowiedź był ograniczony do sześciu żądań na cykl.

To prawdziwy problem. Większość stron internetowych ma w swoim cyklu dziesiątki zapytań. Deweloperzy i administratorzy systemu znaleźli sprytne sposoby na obejście tego ograniczenia.

Jednym z bardziej znanych obejść jest praktyka łączenia plików CSS i JavaScript. W idealnym scenariuszu zmniejszyłoby to całkowitą liczbę żądań plików CSS i JavaScript do dwóch: jedno dla JavaScript i jedno dla CSS.

Nie jest to konieczne w przypadku HTTP/2. HTTP/2 umożliwia nieograniczoną liczbę żądań na połączenie. Dzięki temu wszystkie dodatkowe żądania po początkowej odpowiedzi HTML mogą wystąpić w tym samym czasie.

Ma to ogromny wpływ na wydajność. Wiele pracy związanej z optymalizacją stosu serwerów skupia się na cyklu żądanie-odpowiedź. Zmniejszając liczbę cykli do zaledwie kilku, HTTP/2 wykonał dla nas ogromną pracę.

Pamięć podręczna HTTP

Najważniejszą częścią współczesnego stosu serwerów WordPress jest pamięć podręczna HTTP. W świecie WordPressa nazywamy to również buforowaniem strony. Celem bufora HTTP jest buforowanie odpowiedzi na żądania. Co to znaczy?

Cóż, wróćmy do naszego wcześniejszego przykładu. Przeglądarka wysyła żądanie dotyczące strony domowej modern.wordpress-stack.org , a serwer WWW odbiera to żądanie i przekazuje je do PHP.

Problem z tym scenariuszem polega na tym, że serwer sieciowy jest głupi. Zawsze przekaże wszystkie otrzymane żądania do PHP — niezależnie od tego, czy większość żądań generowałaby taką samą odpowiedź.

To jest dokładnie to, co dzieje się, gdy odwiedzający nie są zalogowani. Dla serwera internetowego są to różne żądania, ale to nie obchodzi. Przekaże je wszystkie do PHP, który wygeneruje tę samą odpowiedź dla nich wszystkich.

To straszne! Jak widzieliśmy wcześniej, PHP jest prawdziwym wąskim gardłem naszego cyklu żądanie-odpowiedź. Twoja przeglądarka nie może wysyłać dalszych żądań, dopóki nie otrzyma początkowej odpowiedzi na stronę główną. Nie możemy domyślnie przekazywać wszystkiego do PHP przez serwer WWW.

Tu właśnie pojawia się pamięć podręczna HTTP. Znajduje się między serwerem WWW a PHP. Jego zadaniem jest sprawdzanie każdego żądania odbieranego przez serwer WWW i szukanie odpowiedzi w pamięci podręcznej. Jeśli nie ma, prześle żądanie do PHP, a następnie buforuje odpowiedź wygenerowaną przez PHP.

To drastycznie skraca czas cyklu żądanie-odpowiedź, dzięki czemu strona ładuje się szybciej. Pozwala także serwerowi WWW obsługiwać więcej jednoczesnych żądań bez wysadzania.

Różne smaki pamięci podręcznej HTTP

W tym momencie powinieneś się zastanawiać: „Jak mogę jak najszybciej umieścić to dziecko na moim serwerze?!” Dobrą wiadomością jest to, że instalacja pamięci podręcznej HTTP na serwerze WordPress jest dość łatwa. Jest to komponent o najszerszym zakresie opcji.

Zainstaluj wtyczkę do buforowania stron

Najprostszym sposobem jest zainstalowanie wtyczki do buforowania stron. Masz do wyboru kilka opcji:

• Pamięć podręczna
• Nadmierna pamięć podręczna
• Włącznik pamięci podręcznej
• Rakieta WP
• WP Super Cache
• W3 Całkowita pamięć podręczna

Wszystkie oprócz WP Rocket są dostępne jako bezpłatne wtyczki w katalogu WordPress. Możesz więc zainstalować jeden i od razu go przetestować. Biorąc to pod uwagę, z czterech wtyczek najlepszą jest WP Rocket. Chociaż jest to płatna wtyczka, umożliwia znacznie więcej niż tylko tworzenie pamięci podręcznej HTTP. Te inne korzyści zwiększają pracę wykonywaną przez pamięć podręczną HTTP.

Jak działa wtyczka do buforowania stron?

Wszystkie te wtyczki wykorzystują drop-in, który WordPress udostępnił do buforowania. Ta podręczna pamięć podręczna umożliwia wtyczkom tworzenie systemu pamięci podręcznej HTTP w WordPressie. Pamięć podręczna potrzebuje dwóch rzeczy do działania.

Po pierwsze, plik drop-in advanced-cache.php musi znajdować się w folderze wp-content . To jest właściwy plik. Ale w przeciwieństwie do większości wstawek WordPress, ten nie uruchamia się domyślnie. WordPress potrzebuje również stałej WP_CACHE , aby była true , aby załadować drop-in. W większości przypadków ustawisz to w wp-config.php .

Powyższy diagram pokazuje, co się stanie, gdy włączysz drop-in z wtyczką buforującą. WordPress ładuje drop-in w wp-settings.php podczas procesu ładowania. To na tyle wcześnie, że WordPress nie zrobił jeszcze niczego czasochłonnego.

Wtyczka buforująca sprawdzi następnie, czy już buforowała odpowiedź na żądanie. Jeśli tak, zwróci tę zbuforowaną odpowiedź. Jeśli nie, włączy buforowanie wyjścia PHP, a WordPress będzie kontynuował ładowanie.

Teraz buforowanie wyjścia jest interesującym systemem. To, co robi, to przechwytywanie wszystkich danych wyjściowych ze skryptu PHP w zmiennej łańcuchowej, dopóki nie wydarzy się jedna z dwóch rzeczy:

• każesz PHP zatrzymać buforowanie wyjścia za pomocą jednej z wbudowanych funkcji,
• skrypt PHP kończy działanie i musi zwrócić odpowiedź do przeglądarki.

Wtyczka buforująca liczy na ten drugi scenariusz. Chce, aby WordPress zrobił swoje, a następnie buforował całe dane wyjściowe, zanim PHP odeśle je z powrotem do przeglądarki. Proces można zobaczyć na poniższym schemacie.

Niech serwer WWW to zrobi

Kolejną opcją jest dodanie pamięci podręcznej HTTP na poziomie serwera WWW. Sposób działania polega na tym, że serwer WWW przechowuje w pamięci podręcznej wszystkie odpowiedzi na żądania, które są przekazywane do PHP. To rozwiązanie jest lepsze niż wtyczka buforująca, ponieważ w ogóle nie musi dotykać PHP.

Powyższy diagram przedstawia przegląd tego, co dzieje się na serwerze WWW. Serwer WWW odbiera żądanie i sprawdza w pamięci podręcznej HTTP. Jeśli odpowiedź została już zbuforowana, pamięć podręczna HTTP odeśle ją z powrotem.

W przeciwnym razie przekaże żądanie do modułu PHP (zwykle FastCGI). Przekaże żądanie do WordPressa, aby mógł wygenerować odpowiedź. Moduł pamięci podręcznej HTTP zapisze tę odpowiedź w pamięci podręcznej w drodze powrotnej.

Zarówno Apache, jak i nginx mają możliwość dodania systemu pamięci podręcznej HTTP. Moduł nginx jest wbudowany. Apache to oddzielny moduł, który musisz dodać do swojej instalacji Apache.

Nie ma zbyt wielu informacji o tym, jak korzystać z modułu Apache w PHP lub WordPress. Może to wynikać z tego, że nie jest popularny wśród tłumu Apache, a może dlatego, że ma pewne problemy. Jest z tym co najmniej jeden zadawniony problem, który wciąż pozostaje otwarty.

Tymczasem system pamięci podręcznej HTTP nginx jest solidny i dobrze udokumentowany. Możesz go używać jako zwykłej pamięci podręcznej HTTP lub mniejszej, ale efektywnej mikro-pamięci podręcznej. To jeszcze jeden powód, dla którego nginx jest obecnie preferowanym serwerem WWW.

Dodaj lakier do stosu

Co to jest lakier? Jest to dedykowany serwer pamięci podręcznej HTTP (lub, jak lubią go nazywać jego twórcy, akcelerator HTTP). Większość witryn o dużym natężeniu ruchu i firm hostingowych premium używa go jako rozwiązania pamięci podręcznej HTTP.

Używają go, ponieważ jest potężny i oferuje największą elastyczność. Varnish posiada własny język konfiguracyjny o nazwie VCL. Pozwala kontrolować każdy element procesu buforowania. Varnish zawiera również wiele narzędzi do analizy tego, co robi pamięć podręczna i jak działa.

Oto główne różnice między używaniem go a korzystaniem z wbudowanej pamięci podręcznej HTTP serwera WWW. Wbudowana pamięć podręczna HTTP serwera WWW jest super wydajna, ale także dość prosta. Nie masz dużej kontroli poza kilkoma opcjami konfiguracji.

Niemniej jednak ta moc i elastyczność mają swoją cenę. Lakier jest również najbardziej skomplikowaną opcją pamięci podręcznej HTTP. Nie robi nic poza buforowaniem odpowiedzi HTTP. Nie obsługuje zakończenia SSL, czego większość programistów WordPress chce (lub powinna chcieć). Oznacza to, że nasz nowoczesny stos serwerów WordPress będzie bardziej złożony, gdy go użyjemy.

Powyższy diagram ilustruje tę dodatkową złożoność. Mamy teraz dwa dodatkowe komponenty w naszym stosie serwerów WordPress: lakier i odwrotny serwer proxy.

Odwrotny serwer proxy ma na celu przezwyciężenie ograniczeń, jakie Varnish ma z SSL. Znajduje się przed Varnish i odszyfrowuje żądania, które otrzymuje nasz serwer. Ten typ zwrotnego serwera proxy można również nazwać serwerem proxy zakończenia protokołu SSL. Proxy następnie wysyła te odszyfrowane żądania do Varnisha w celu przetworzenia.

Gdy żądanie trafi do Varnisha, plik(i) konfiguracyjny VCL uruchamiają się. Są mózgiem Varnisha. Na przykład mówią mu, jak:

• analizować, czyścić i modyfikować przychodzące żądania;
• poszukaj odpowiedzi w pamięci podręcznej;
• analizować, czyścić i modyfikować powracające odpowiedzi z WordPressa;
• buforuj te powracające odpowiedzi;
• obsłużyć żądanie usunięcia jednej lub więcej odpowiedzi z pamięci podręcznej.

Ten ostatni jest szczególnie ważny. Pozostawiony sam sobie, Varnish nie ma możliwości sprawdzenia, kiedy WordPress chce usunąć stronę z pamięci podręcznej. Tak więc domyślnie, jeśli wprowadzisz zmiany w poście i zaktualizujesz go, odwiedzający będą nadal widzieć tę samą stronę w pamięci podręcznej. Na szczęście dla nas istnieje wtyczka, która usuwa strony z pamięci podręcznej Varnish.

WordPress

W porządku, nasza prośba o stronę modern.wordpress-stack.org trafiła do WordPressa. Przeszedł przez cykl żądanie-odpowiedź, który właśnie omówiliśmy. Pamięć podręczna HTTP zrobiła wszystko, co w jej mocy, aby znaleźć odpowiedź HTTP do odesłania.

Ale nie było buforowanej odpowiedzi HTTP, którą można by wysłać z powrotem do przeglądarki. W tym momencie pamięć podręczna HTTP nie miała innego wyjścia. Musiał przekazać żądanie HTTP do WordPressa.

Wszystko jest teraz w rękach WordPressa. WordPress musi przekształcić nasze żądanie HTTP w odpowiedź HTTP i odesłać je z powrotem do pamięci podręcznej HTTP. Jak widzieliśmy wcześniej, jest to główne wąskie gardło całego naszego nowoczesnego stosu serwerów WordPress.

Przyczyna tego wąskiego gardła jest dwojaka. WordPress ma dużo kodu PHP do wykonania. Jest to czasochłonne, a im wolniej PHP to robi, tym dłużej to trwa.

Drugim wąskim gardłem są zapytania do bazy danych, które WordPress musi wykonać. Zapytania do bazy danych to kosztowne operacje. Im ich więcej, tym wolniejszy jest WordPress. To będzie temat ostatniej sekcji cyklu zapytania-wynik.

Optymalizacja środowiska wykonawczego PHP

Wróćmy do PHP. W tej chwili WordPress ma minimalne wymagania PHP 5.2. Ta wersja PHP ma już prawie 10 lat! (Zespół PHP przestał go wspierać w 2011 roku.)

Zespół PHP nie siedział bezczynnie przez te wszystkie lata. Wprowadzono wiele ulepszeń wydajności, zwłaszcza w ciągu ostatnich kilku lat. Przyjrzyjmy się, co możesz zrobić, aby go zoptymalizować w dzisiejszych czasach.

Użyj najnowszej wersji PHP

Najłatwiejszą rzeczą, jaką możesz zrobić, to zaktualizować swoją wersję PHP. Wersje 5.4, 5.5 i 5.6 poprawiły wydajność. Największa poprawa wyniosła z 5,3 do 5,4. Przejście na niego zwiększyło wydajność WordPressa o przyzwoitą kwotę.

Zainstaluj buforowanie kodu operacji

Buforowanie opcode to kolejny sposób na przyspieszenie PHP. Jako język skryptowy po stronie serwera, PHP ma dużą wadę: musi kompilować skrypt PHP za każdym razem, gdy go wykonuje.

Rozwiązaniem tego problemu jest buforowanie skompilowanego kodu PHP. W ten sposób PHP nie musi go kompilować za każdym razem, gdy go wykonuje. To jest zadanie pamięci podręcznej kodu operacji.

Przed PHP 5.5 PHP nie było dostarczane w pakiecie z pamięcią podręczną kodu operacji. Musiałeś sam go zainstalować na serwerze. To kolejny powód, dla którego korzystanie z nowszej wersji PHP jest lepsze.

Przejdź na kompilator nowej generacji

Ostatnią rzeczą, jaką możesz zrobić, to przełączyć się na jeden z dwóch kompilatorów nowej generacji: HHVM Facebooka lub PHP 7, najnowszą wersję PHP. (Dlaczego PHP 7? To długa historia.)

Facebook i zespół PHP zbudowali te dwa kompilatory od podstaw. Chcieli wykorzystać bardziej nowoczesne strategie kompilacji. HHVM używa kompilacji just-in-time, podczas gdy PHP 7 używa kompilacji z wyprzedzeniem. Oba oferują niesamowitą poprawę wydajności w stosunku do starego dobrego PHP 5.

HHVM był pierwszym, który pojawił się na scenie kilka lat temu. Wiele hostów z najwyższej półki odniosło z nim wiele sukcesów, oferując go jako główny kompilator PHP.

Warto jednak podkreślić, że HHVM nie jest oficjalnym kompilatorem PHP. Nie jest w 100% kompatybilny z PHP. Powodem jest to, że HHVM nie jest przeznaczony tylko do obsługi PHP; jest to również kompilator języka programowania Facebook Hack.

PHP 7 to oficjalny kompilator PHP. Nie było tego od dawna. Zespół PHP wydał go w grudniu 2015. Nie przeszkodziło to niektórym firmom hostingowym WordPress już go wspierać.

Dobrą wiadomością jest to, że sam WordPress jest w 100% kompatybilny z obydwoma kompilatorami! Zła wiadomość jest taka, że ​​nie wszystkie wtyczki i motywy są takie, ponieważ minimalna wersja PHP dla WordPressa to wciąż 5.2.

Nic nie zmusza autorów, aby ich wtyczki lub motywy działały z tymi kompilatorami. Więc nie możesz wejść na całość z jednym z nich. Twój stos powinien zawsze wracać do PHP 5.

Cykl zapytanie-wynik

W tym momencie środowisko wykonawcze PHP przegląda wszystkie pliki WordPress PHP i wykonuje je. Jednak te pliki WordPress PHP nie zawierają żadnych danych. Zawierają tylko kod WordPress.

Problem polega na tym, że WordPress przechowuje wszystkie swoje dane w bazie danych MySQL. Tak więc, aby się do tego dostać, środowisko wykonawcze PHP musi wykonać zapytanie do tej bazy danych. Serwer MySQL zwraca wynik tego zapytania, a środowisko wykonawcze PHP kontynuuje wykonywanie plików WordPress PHP… cóż, to znaczy, dopóki nie będzie ponownie potrzebować danych.

To tam i z powrotem może się zdarzyć od kilkudziesięciu do kilkuset razy. (Możesz porozmawiać ze swoim programistą, jeśli to drugie!) Dlatego jest to główne wąskie gardło.

Optymalizacja cyklu zapytanie-wynik

Celem optymalizacji jest tutaj przyspieszenie czasu wykonywania plików WordPress przez PHP. W tym miejscu zapytania do bazy danych są problematyczne. Zwykle zabierają więcej czasu niż tylko uruchomienie zwykłego kodu PHP (chyba że twój kod robi coś skandalicznego).

Oczywistym sposobem rozwiązania tego problemu jest zmniejszenie liczby zapytań, które WordPress musi wykonać. A to zawsze się opłaca! Ale nie jest to coś, w czym może pomóc współczesny stos serwerów WordPress.

Możemy nie być w stanie zmniejszyć liczby zapytań, które wykonuje WordPress, ale nie brakuje nam też opcji. Nadal istnieją dwa sposoby, w jakie stos może pomóc nam zoptymalizować cykl zapytanie-wynik. W pierwszej kolejności może zmniejszyć liczbę zapytań do bazy danych. A w przypadku zapytań, które trafiają do bazy danych, może to skrócić czas ich uruchomienia.

Obie te opcje mają na celu to samo: sprawić, by PHP jak najkrócej czekało na wyniki z bazy danych, co przyspieszy sam WordPress.

Elementy stosu dla cyklu zapytanie-wynik

Przyjrzyjmy się różnym elementom stosu zaangażowanym w cykl zapytania-wynik. Ta część stosu jest mniej złożona. Ale nadal obejmuje więcej niż jeden komponent — a mianowicie serwer bazy danych MySQL i pamięć podręczną obiektów.

Serwer bazy danych MySQL

Kilka lat temu serwer bazy danych MySQL oznaczałby to samo dla wszystkich. Był to serwer z zainstalowanym serwerem MySQL. Ale w ostatnich latach wiele się zmieniło.

Różne grupy nie były zadowolone z tego, jak Oracle zarządzało projektem MySQL. Tak więc każda grupa rozwidlała go i stworzyła własną wersję, do której można było „wpaść”. W rezultacie istnieje teraz kilka serwerów baz danych MySQL.

Nowym „oficjalnym” serwerem MySQL jest serwer MariaDB. Jest to opracowana przez społeczność wersja serwera MySQL. Społeczność planuje zachować pełną kompatybilność z projektem serwera MySQL.

Inną popularną alternatywą dla MySQL jest serwer Percona. W przeciwieństwie do MariaDB, Percona jest bardziej gałęzią MySQL. Jego twórcy nie są przeciwni samemu projektowi MySQL; chcą po prostu skupić się na poprawie wydajności MySQL. Zespół MariaDB później połączył niektóre z tych ulepszeń wydajności w projekcie MariaDB.

Na koniec dnia możesz wybrać ten, który wolisz. Nie ma różnicy w wydajności między serwerem Percona a serwerem MariaDB (w każdym razie dla większości z nas). Obie działają lepiej niż MySQL. Percona zachowuje jednak bliższą kompatybilność z projektem Oracle.

To, co wpływa na wydajność, to silnik pamięci , z którego korzysta baza danych WordPress. Silnik pamięci masowej kontroluje sposób, w jaki serwer bazy danych zarządza przechowywanymi przez siebie danymi. Możesz również ustawić inny aparat przechowywania dla każdej tabeli bazy danych; nie musisz używać tego samego dla całej bazy danych.

Serwer bazy danych ma kilka silników pamięci masowej. Nie przyjrzymy się wszystkim. Interesują nas tylko dwie: InnoDB i MyISAM.

Domyślnie WordPress używa domyślnego silnika bazy danych MySQL. Przed MySQL 5.5 tym silnikiem był MyISAM. Jeśli prowadzisz małą witrynę WordPress, MyISAM jest w porządku. MyISAM napotyka problemy z wydajnością, gdy strona internetowa powiększa się. W tym momencie InnoDB jest jedynym wyborem dla silnika bazy danych.

Jedynym problemem z InnoDB jest to, że wymaga pewnego dostrojenia, aby działać jak najlepiej. Jeśli używasz dużego serwera bazy danych, może być konieczne dostosowanie rzeczy. Na szczęście dla nas jest narzędzie, które w tym pomoże.

MySQLTuner to mały skrypt, który analizuje serwer bazy danych. Wygeneruje raport i poda zalecenia dotyczące strojenia.

Pamięć podręczna obiektów

Główny ciężar pracy nad optymalizacją cyklu zapytania-wynik leży w pamięci podręcznej obiektów. Zadaniem pamięci podręcznej obiektów jest przechowywanie danych, których pobranie lub wygenerowanie jest czasochłonne. Jak można się domyślić, zapytania do bazy danych są idealnymi kandydatami.

WordPress bardzo często korzysta z pamięci podręcznej obiektów. Powiedzmy, że używasz get_option , aby pobrać opcję z bazy danych. WordPress wyśle ​​zapytanie do bazy danych tylko raz. Nie będzie pytać o to ponownie, gdy ktoś będzie tego potrzebował.

Zamiast tego WordPress pobierze wynik zapytania z pamięci podręcznej obiektów. Jest to proaktywny krok, który WordPress podejmuje, aby zmniejszyć liczbę zapytań do bazy danych, które musi wykonać. Ale to nie jest niezawodne rozwiązanie.

Chociaż WordPress dołoży wszelkich starań, aby wykorzystać pamięć podręczną obiektów, wtyczka lub motyw nie muszą. Jeśli wtyczka lub motyw wykonuje wiele zapytań do bazy danych i nie buforuje wyników, stos nie może nic z tym zrobić.

W takich przypadkach większość zapytań do bazy danych będzie pochodzić z samego WordPressa. W ten sposób uzyskasz duży przebieg dzięki wbudowanemu wykorzystaniu pamięci podręcznej obiektów przez WordPress. Dlatego jest ważnym elementem współczesnego stosu serwerów WordPress.

Teraz problem z pamięcią podręczną obiektów polega na tym, że domyślnie nie utrwala danych, które przechowuje. Po prostu przechowuje dane w pamięci, podczas gdy PHP wykonuje wszystkie pliki WordPress. Ale kiedy proces PHP się zakończy, wszystkie dane przechowywane w pamięci zostają wyczyszczone.

To wcale nie jest idealne. Pamięć podręczna obiektów może pozostać ważna przez długi czas, więc nie chcesz ograniczać jej do pojedynczego żądania. Rozwiązaniem jest użycie trwałej pamięci podręcznej obiektów .

Trwała pamięć podręczna obiektów często występuje w postaci wtyczki. Ta wtyczka korzystałaby z drop-in object-cache.php do wykonania swojej pracy. Ta lista rozwijana pozwala autorom wtyczek zmienić domyślne zachowanie pamięci podręcznej obiektów.

Wtyczki następnie łączą pamięć podręczną obiektów z trwałym magazynem danych. Robią to, zastępując funkcję pobierania i zapisywania domyślnej pamięci podręcznej obiektów. Zamiast zapisywać i pobierać dane do pamięci, pamięć podręczna obiektów robi to z tego magazynu.

Wtyczki trwałej pamięci podręcznej obiektów

Obecnie istnieją dwie popularne opcje przechowywania danych do trwałego buforowania obiektów:

• Memcached (wtyczka)
• Redis (wtyczka)

Oba te magazyny danych używają pamięci RAM do przechowywania, co czyni je błyskawicznymi. W rzeczywistości ich wydajność jest porównywalna z wydajnością domyślnej pamięci podręcznej obiektów.

Jedynym problemem jest to, że nie są one preinstalowane na serwerach. Podobnie jak ich rozszerzenie PHP (które jest opcjonalne w Redis). Musisz go zainstalować, zanim będziesz mógł korzystać z odpowiedniej wtyczki WordPress.

Który powinieneś zainstalować? W praktyce nie ma między nimi dużej różnicy w przypadku buforowania obiektów. W przeszłości popularną opcją był Memcached. Zmieniło się to w ciągu ostatnich kilku lat. Redis dodał wiele funkcji, które sprawiły, że jest to najważniejsza opcja do buforowania obiektów.

Zdobycie własnego nowoczesnego serwera WordPress

Jak więc zdobyć własny serwer? Oczywistym sposobem jest zdobycie jednego z czołowych firm hostingowych WordPress. Firmy te chcą pozostać w czołówce branży hostingowej WordPress, co motywuje je do przyjmowania najnowszych przełomów i technologii.

Ale co, jeśli chcesz go mieć bez rozbijania banku? Kilka narzędzi jest dostępnych dla każdego, kto woli zrobić to sam i zapłacić mniej za hosting. Przyjrzyjmy się im.

DebOps dla WordPressa

DebOps for WordPress to narzędzie, które stworzyłem, aby pomóc każdemu zbudować nowoczesny serwer WordPress. Jego misją jest udostępnienie nowoczesnego stosu serwerów WordPress dla każdego członka społeczności. Dlatego staram się, aby korzystanie z niego było jak najłatwiejsze. Nie potrzebujesz żadnej wiedzy z zakresu administrowania systemem, aby z niego korzystać.

DebOps dla WordPressa konfiguruje serwer z następującymi parametrami:

• HHVM (dopóki PHP 7 nie stanie się oficjalnym repozytorium Linuksa)
• MariaDB
• nginx
• Redis
• Lakier

Narzędzie to nie tylko konfiguruje serwer z najnowszymi technologiami. Dba również o zabezpieczenie serwera dla Ciebie. To jest coś, co ludzie często przeoczają, zarządzając własnym serwerem.

EasyEngine

EasyEngine to narzędzie wiersza poleceń zaprojektowane, aby pomóc Ci skonfigurować witrynę WordPress na serwerze. Wspaniałą rzeczą w EasyEngine jest jego elastyczność: można go używać do konfiguracji niemal dowolnej kombinacji technologii serwerowych, które analizowaliśmy do tej pory.

Na przykład pozwala skonfigurować serwer z HHVM lub PHP 7. Pozwala wybrać między Memcached i Redis dla trwałego magazynu danych. I pozwala zainstalować narzędzia administracyjne, takie jak phpMyAdmin.

Oferuje również wiele opcji podczas tworzenia witryny WordPress. Możesz powiedzieć mu, aby skonfigurował stronę internetową z pamięcią podręczną HTTP za pomocą wtyczki lub nginx. Cała ta elastyczność sprawia, że ​​EasyEngine jest tak popularnym narzędziem.

Krata

Trellis to narzędzie opracowane przez Roots. Podobnie jak DebOps, konfiguruje serwer za pomocą określonego zestawu technologii serwerowych:

• MariaDB
• Memcached
• nginx
• Pamięć podręczna HTTP nginx (opcjonalnie)
• PHP 7

Jedną rzeczą, którą należy wiedzieć o Trellis, jest jej związek z Bedrock, kolejnym narzędziem stworzonym przez Roots. Bedrock jest szablonem do budowania witryny WordPress wokół zasad „Twelve-Factor App”.

Zespół Roots stworzył Trellis, aby umożliwić ludziom skonfigurowanie serwera, który wykorzystuje witryny WordPress o strukturze Bedrock. Nie możesz go używać z normalną instalacją WordPressa, więc miej to na uwadze.

Czasy się zmieniły

Jak widać, serwer WordPress ma dziś o wiele więcej ruchomych części! Ale to nie musi być powodem do rozpaczy. Nie jest tak źle, jak się wydaje, ponieważ nie zawsze musisz używać wszystkich części.

Dlatego tak wiele w tym artykule omawia, jak te części współpracują ze sobą. Chodzi o to, abyś mógł podejmować własne decyzje. Wykorzystaj tę wiedzę, aby zdecydować, których części i kiedy będziesz potrzebować. W ten sposób Ty również będziesz miał szybką witrynę WordPress.