Jak dobrze skaluje się WordPress?

Dzięki nowemu WordPressowi i jego nowym funkcjom wydaje się, że WordPress jest w stanie znacznie więcej niż zwykły silnik blogów. Ale jak dobrze skala WordPress jest używana przez powiedzmy 10 000 -> 100 000 użytkowników dziennie?

Dzięki temu wielu użytkowników będzie w dużej mierze mieć dobrą strategię pamięci podręcznej, ale jak dobrze WordPress został opracowany, aby pomóc, dzięki czemu jest to łatwe i daje ci kontrolę, której potrzebujesz. Fx może buforować część strony i renderować tylko części niestandardowe, obsługiwać konfigurację db master / slave i tym podobne?

Oczywiście nic się nie skaluje, podobnie jak pliki statyczne obsługiwane przez szybki serwer WWW i każdy CMS, który musi dowiedzieć się, co załadować, a następnie załadować, ale nie będzie działał tak dobrze, WordPress lub w inny sposób. Jednym z problemów jest liczba zapytań do bazy danych na żądanie adresu URL i moje 2 lata doświadczenia w pracy wyłącznie z Drupal, a teraz ponad 2 lata z WordPress jest taki, że WordPress jest znacznie lepszy w tym dziale.

To powiedziawszy, prawie nic z żadną mocą nie skaluje się „od razu po wyjęciu z pudełka” ; chodzi o to, co możesz zrobić, gdy rosną Twoje potrzeby w zakresie skalowalności?

Na niskim końcu „ dużego ruchu” znajdują się świetne wtyczki buforowania i integracje z niedrogimi sieciami CDN, które można wykonać całkiem dobrze przy budżecie bez IT i niskim budżecie hostingu. Oto kilka innych pytań i odpowiedzi do recenzji:

• Jak zoptymalizować WordPress pod względem obciążenia serwera?
• Opcje dla CDN z WordPress, w tym obsługa wtyczek?
• Konfigurujesz WordPress dla Amazon CloudFront Caching?

Istnieją opcje profilowania w celu zidentyfikowania wąskich gardeł wydajności :

• Profilowanie witryny WordPress w celu wdrożenia na Shared Hosting?

Po zidentyfikowaniu wąskich gardeł można przeprowadzić zlokalizowaną optymalizację za pomocą takich funkcji, jak interfejs API transjentów . Niniejsze pytania i odpowiedzi dają przykład, który można zoptymalizować za pomocą interfejsu API transjentów i pokazują, jak:

• Używasz WP_Query do zapytania o wiele kategorii z ograniczoną liczbą postów według kategorii?

Jeśli naprawdę chcesz wyciągnąć duże pistolety , możesz skonfigurować Memcached , HyperDB , Nginx i / lub więcej, aby przyspieszyć (wydaje się, że ten ostatni naprawdę ewoluuje w kierunku uzyskania niesamowitej skalowalności z WordPress):

• Włącz Memcached dla WordPress
• Jak przyspieszyć WordPress dzięki Nginx i WP Super Cache
• HyperDB
• Nginx jako front-cache proxy dla WordPress

I wreszcie pojawiają się webhosty ukierunkowane na WordPress specjalizujące się w wydajności, takie jak WP Engine , ZippyKid i inne:

• Najlepsze cechy rasy wysokiej klasy hosta WordPress?

Więc dobrą wiadomością jest to wszystkich skalach bardzo ładnie ; od bardzo niskiego końca darmowy i łatwy z techniczną złożonością, a koszty rosną tylko wraz ze znacznym wzrostem ruchu. Zacznij od małego z WordPress, a będzie świetnie. Jeśli Twój ruch rośnie i zarabiasz go dość dobrze, przekonasz się, że jest to bardzo opłacalne, jeśli chcesz go skalować.

Przynajmniej IMO. :)

1. Nie oczekuj wiele od hostingu współdzielonego - nie obwiniaj WordPressa o powolność, jeśli korzystasz z hosta współdzielonego. Hosty współdzielone mogą upchnąć tysiące kont na jednym serwerze. Możesz więc spędzić cały dzień na optymalizacji konta o wartości 10 USD miesięcznie, a to nie będzie miało znaczenia. Uważaj także na modne hasła marketingowe - tylko dlatego, że napis „chmura” nie oznacza, że ​​nie udostępniasz jednego serwera setkom lub tysiącom osób.

2. Nie sądzę, aby wtyczki pamięci podręcznej były w tym momencie potrzebne. Jeśli spojrzysz na kod źródłowy WP, w jądrze jest już zaawansowane buforowanie. Pamięć podręczna pamięci podręcznej pamięci podręcznej - uważaj, może to przynieść efekt przeciwny do zamierzonego.

3. Najważniejsze, co spowalnia cię, to powolne zapytania MySQL, a WordPress nie powinien sprawiać kłopotów. Musiałem jednak „OGRANICZYĆ” moje zapytania o komentarze, ponieważ miałem ponad 50 000 komentarzy. (Czy to już zostało naprawione?) Ponadto, jeśli robisz coś nietypowego (np. 1000 kategorii?), Może to również stanowić problem.

4. Używam Linode 512 z NginX, a „top” pokazuje, że PHP i NginX wykonują swoją pracę w mniej niż 1/100 sekundy na żądanie. Prawie cały czas pracy procesora jest związany z MySQL. Mógłbyś obsłużyć 1 milion stron miesięcznie za pomocą Linode za 20 USD, ale kiedy zaczniesz dodawać wtyczki i zdjęcia, myślę, że będziesz potrzebował Linode „1 GB”. Z mojego punktu widzenia jest to prawie liniowe: jeśli liczba odsłon strony się podwoi, wystarczy podwoić rozmiar Linode.

Oświadczenie: Nie pracuję dla Linode.

Zaktualizuj (~ 2 lata później), ponieważ chcesz buforować części strony za pomocą PHP, oto proste rozwiązanie, którego używam, które jest zaskakująco szybkie. Przechowuję w pamięci podręcznej kilka oddzielnych części / porcji na stronę w ciągu 1/100 sekundy. Wygląda na to, że ramdysk może to zrobić jeszcze szybciej, ale jest wystarczająco szybki jak na moje potrzeby:

$cache_file = "./cache/portion-1". $since; // maybe round() this $since timestamp
$cache_life = 1000; // seconds to keep this cached
$filemtime = filemtime($cache_file);  // returns FALSE if file does not exist
if (!$filemtime or (time() - $filemtime >= $cache_life)) {

    // heavy lifting starts
    $output = 'Heavy!';
    // heavy lifting ends

    if (!file_put_contents($cache_file,$output,LOCK_EX)) { echo 'error'; } // save the cache    
    echo $output;

} else { 

    // load from cache
    $output = file_get_contents($cache_file); 
    echo $output;        
} 

Ostatecznie są 3 rzeczy, które spowalniają WordPress na dużą skalę i sprowadzają się do tego:

• Hosting stack - potrzebujesz dobrego hosta z najnowszym oprogramowaniem - PHP 7, Nginx, Varnish, Redis, fail2ban i PerconaDB to dobry wybór
• Brak skanowania tabeli - wiele wtyczek jest pisanych przez koderów-amatorów, którzy nawet nie wiedzą, co to jest skanowanie tabeli. Aby uniknąć skanowania tabeli, potrzebne są dwie rzeczy - użyteczny indeks i zapytanie napisane w taki sposób, aby można było z niego korzystać
• Brak zapytań SQL lub kilka zapytań wewnątrz pętli PHP - niektóre kody wtyczek zostały wyraźnie przetestowane tylko na małych stronach, z tego czy innego powodu przejdzie przez każdy produkt w bazie danych i wykona nowe wywołanie SQL dla każdego produktu / posta. Idealnie potrzebujesz mniej niż 100 zapytań SQL na stronę - brzmi to dużo, ale to nie jest tak naprawdę, a przy <100 otrzymasz TTFB około 200 ms bez buforowania.

Gdy już wprowadzisz powyższe, możesz dodać buforowanie - np. Lakier, CDN, buforowanie stron itp.

Jeśli chcesz skalować, możesz utworzyć klaster za pomocą PerconaDB XtraDB dla bazy danych i Unison dla plików. W ten sposób możesz mieć 1 węzeł jako wp-admin i cron runner, a pozostałe węzły obsługują ruch sieciowy za modułem równoważenia obciążenia.