WordPress – Wysokie obciążenie serwera (procesora).

Większość firm hostingowych w Polsce oferuje preinstalowane skrypty gotowych systemów. Praktycznie w każdej ofercie jest WordPress (jedna z najpopularniejszych platform blogowych). Problem zaczyna pojawiać się w momencie gdy wykupimy hosting współdzielony. Generowane obciążenie przez skrypty ma znaczenie dla innych użytkowników, a administratorzy chcą upchnąć jak największą liczbę kont na jednym serwerze. Im więcej użytkowników tym mniejsze widełki czasu procesora przewidziane na pojedyncze konto (tzw. Overselling). Momentalnie zaczynamy dostawać e-maile o zbyt wysokim obciążeniu serwera od sfrustrowanych administratorów. Zaczyna się odbijanie piłeczki i walka o minimalizację zużycia zasobów, zwłaszcza jeżeli nasz blog cieszy się sporym powodzeniem. Pojawiają się zarzuty, albo nasz WordPress ma zbyt dużą ilość zainstalowanych wtyczek co powoduje spore obciążenie albo mamy błędnie skonstruowane szablony: nieprawidłowo zaimplementowane pętle pobierające dane itp. Postanowiłem to sprawdzić oczywiście najpierw poszukałem informacji na temat najczęstszych przyczyn.

Porównałem prędkość przetwarzania dla różnych przypadków: WordPress 3.x, 2.x, dołączenie popularnych wtyczek, szablon standardowy oraz mój + dodatkowe modyfikacje.

Na jednym z blogów dokopałem się do ciekawej informacji, twórca twierdzi że brak ikony (favicon.ico) powoduje skok obciążenia serwera o 400%.

Najpierw trochę faktów hosting, na którym stoi ten serwis: superhost.pl. Nigdzie nie można dokopać się do informacji jaki czas procesora jest przewidziany dla użytkownika jako maksymalne obciążenie,  podany jest jedynie limit zapytań do bazy danych. Szkoda, konkurencja np. nazwa.pl jasno informuje jakie są ograniczenia jeśli chodzi o zasoby.

W moim przypadku WordPress przy stosunkowo małym ruchu (obciążenie przy „aktywnym” korzystaniu/testowaniu) generował obciążenie przekraczające „dopuszczalne” wartości. Największe obciążenie generował oczywiście index.php , wp-cron.php oraz admin-ajax.php.

A więc do testów (wyświetlenie czasu generowania strony oraz ilość zapytań do bazy danych można uzyskać posługując się funkcjami: timer_stop oraz get_num_queries).

Ponieważ czasy generowania stron na serwerze superhost.pl były bardzo zbliżone do jednej z maszyn którą posiadam (+/- 5% Core 2 Duo @1.8 GHz) postanowiłem przeprowadzać testy lokalnie w celu eliminacji czynników dodatkowych (obciążenie serwera przez inne procesy). Najpierw przeglądanie logów z serwera w celu weryfikacji informacji o obciążeniu spowodowanym brakiem favicon. Acces.log faktycznie w 10% przypadków wywołania strony zawierał informację o próbie uzyskania dostępu do pliku ikony, który nie istniał i nie był zdefiniowany w kodzie xhtml. Wgranie pliku nie zmieniło czasu generowania, a zatem i obciążenia serwera.

Czas na sprawdzenie wpływu uruchomionych wtyczek. W testach użyty został domyślny szablon dla WP 3.x -Twenty Ten 1.1 w ten sposób mamy pewność, że konstrukcja szablonów jest prawidłowa i nie powoduje dodatkowego obciążenia.

Użyte wtyczki:

  • Advanced Excerpt
  • All in One SEO Pack
  • CMS Tree Page View
  • Fast Secure Contact Form
  • Google XML Sitemaps
  • SI CAPTCHA Anti-Spam
  • User Role Editor (Uprawnienia grup)
  • WP-PageNavi
  • WP-Syntax
  • WP Pending Post Notifier
  • WP Super Cache (wyłączona zależy nam na sprawdzeniu obciążenia bez buforowania wyjścia)

Test przeprowadzono dla strony głównej (0 postów) oraz strony postu ze średnią ilością tekstu i zdjęć + dołączenie skryptu lightbox.

Domyślna skórka dla WP 3.x bez żadnych pluginów.

Usługodawca dostarcza WP w wersji 2.8.x, może wina leży po stronie serii 3.x. Dlatego sprawdziłem jakie czasy powstaną przy korzystaniu ze starszej wersji produktu.

Domyślna skórka dla WP 2.8.x bez żadnych pluginów.

Okazuje się, że wersja 3.x jest bardziej oszczędna. Wracamy do testowania serii 3.x.

Test I – 1 wtyczka

  • Advanced Excerpt

Test II – 7 wtyczek

  • Advanced Excerpt
  • All in One SEO Pack
  • CMS Tree Page View
  • Fast Secure Contact Form
  • Google XML Sitemaps
  • SI CAPTCHA Anti-Spam
  • User Role Editor (Uprawnienia grup)

Test III – 10 wtyczek

  • Advanced Excerpt
  • All in One SEO Pack
  • CMS Tree Page View
  • Fast Secure Contact Form
  • Google XML Sitemaps
  • SI CAPTCHA Anti-Spam
  • User Role Editor (Uprawnienia grup)
  • WP-PageNavi
  • WP-Syntax
  • WP Pending Post Notifier

Test IV – 10 wtyczek własny szablon

Dodałem pętle z wyświetlaniem losowych wpisów i kilka innych rzeczy.

Wnioski:

Niestety firma superhost nie jest taka super. Proponują hosting dla platformy, która według nich przy lekkim wykorzystaniu zużywa więcej zasobów niż oferują. Dość spora (10) liczba wtyczek (moim zdaniem bardzo użytecznych dla WP) nie wpływa aż tak znacząco na czas generowania stron. Procentowo jest to wzrost o 32% w przypadku index.php oraz 38% dla single.php jednak czas generowania nie jest jeszcze tragiczny, użycie wtyczki buforującej powinno rozwiązać problem. Własny szablon zawierający dodatkowe pętle pobierające dane również nie wpłynął zbyt mocno na generowane obciążenie, praktycznie bez zmian mimo wzrostu liczby zapytań do bazy danych (dbajcie o indeksy, nie przeprowadzałem testów na wielkiej ilości postów choć specjalnie wrzuciłem trochę śmieci około 1K rekordów).

4 myśli na temat “WordPress – Wysokie obciążenie serwera (procesora).

  • 3 czerwca 2013 o 18:08
    Permalink

    Nie ma wcale większego obciążenia bez wtyczek. Testy przeprowadzałem na wersji 3.x. Pewnie chodzi Ci o wykres obciążenia gdzie porównuję wersję 2.8 do 3.x wersja 3.x jest bardziej oszczędna.

  • 10 kwietnia 2013 o 22:44
    Permalink

    Interesujący artykulik, ciekawe porównanie troszkę mnie dziwią te wskaźniki jak to możliwe że na czystym systemie jest większe obciążenie niż po włączeniu kilku wtyczek ??
    Ciekawe czy ktoś z Was spotkał się z wtyczką do wordpressa wykonująca obliczenia obciążenia poszczególnych wtyczek zainstalowanych na wp ….. szukam czegoś takiego

  • 21 stycznia 2012 o 22:05
    Permalink

    Hej, masz rację nie ma na to jednoznacznej odpowiedzi. Teoretycznie nie ma ograniczeń, skrypt który nie jest wywołany nie generuje przecież obciążenia. Ograniczeniem jest więc ilość odwiedzin jakie da radę obsłużyć serwer. Dodatkowo możliwe, że część stron będzie odwiedzana częściej. Można je zatem zbuforować do formy statycznych stron za pomocą wtyczek chociażby wspomniany WP Super Cache. Wywołanie zbuforowanej strony generuje bardzo małe obciążenie. Według mnie jedyny sposób na oszacowanie to instalacja WP ze wszystkimi dodatkami, które mają być docelowo używane. Zmierzenie czasu generowania strony wymienioną w artykule funkcją w docelowym środowisku. Przeliczenie czasu procesora na okres czasu. Np. Jeżeli czas procesora potrzebny do wygenerowania strony wynosi 0,5 sek. daje nam to możliwość wygenerowania (przy teoretycznym „nierealnym” założeniu równomiernego liniowego rozłożenia ruchu) około 7200 wywołań na godzinę dla instalacji pod jeden rdzeń procesora. Kwestia optymalizacji użycia ramu przez PHP i Apache (WP jest pamięciożerne). Mam nadzieję, że choć trochę przybliżyłem temat.

  • 21 stycznia 2012 o 14:32
    Permalink

    Cześć, bardzo ciekawy wpis, widzę, że orientujesz się w przeliczaniu obciążeń serwera. Mam do Ciebie ile na jednym serwerze dedykowanym będzie mogło działać wordpressów? Wiem, że nie ma na to jednoznacznej odpowiedzi, zależy to od konfiguracji serwera, oraz wtyczek zainstalowanych w tych wordpressach. Ale załóżmy, że jest to taki dedyk: http://www.ovh.pl/serwery_dedykowane/mg_best_of.xml

    Zakładam, że mam serwis wykorzystujący wordpress multi site. Czyli jest to sieć stron postawionych na wordpress, którymi zarządza tak zwany „Site Admin”, który kontroluje wszyskie wordpressy znajdujące się w tej sieci. I mam pytanie, ile wordpressów pociągnie taki serwer? Może lepiej zainteresować się chmurą? Czy będzie ona wystarczająca, jeśli chodzi wydajność? A może jest jeszcze inne rozwiązanie?

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*