Wydajność witryn drupalowych

archetwist, czw., 2008-05-01 14:29

W tym artykule postaram się przedstawić garść metod na polepszenie wydajności witryn korzystających z Drupala. Chodzi w głównej mierze o szybsze ładowanie stron oraz mniejsze wykorzystanie zasobów serwera.

Jednym z narzędzi, które może pomóc zanalizować przyczynę problemów z wydajnością jest moduł Devel. Podaje on informacje o ilości zapytań, które na danej stronie kierowane są do bazy danych, a także jak dużo czasu zajęło ich wykonanie.

Ciekawe rozszerzenie YSlow dla Firefoksa (wymaga wcześniejszego zainstalowania Firebug) ocenia „prędkość” witryny, a także sugeruje ulepszenia. Na stronie Improving Drupal's page loading performance możemy zapoznać się z listą czynników, które bierze pod uwagę YSlow.

Na stronie „Tools for Performance Tuning and Optimization” opisanych jest kilka przydatnych narzędzi systemu Linux.

Od czego zacząć

Drupal posiada własny mechanizm pamięci podręcznej, który w znaczący sposób poprawia wydajność witryny.

Najprostsze poprawki, od których warto zacząć, to włączenie pamięci podręcznej Drupala, a także optymalizacji plików JS i CSS, na podstronie Wydajność działu zarządzania.

Prędkość ładowania strony może również poprawić przesunięcie odwołań do plików JavaScript na jej koniec. Kod <?php print $scripts ?> jest zazwyczaj w drupalowych skórkach umieszczany w sekcji <head>, tymczasem powinien się on znajdować przy końcu, przed <?php print $closure ?>. W ten sposób przeglądarki nie będą opóźniać ładowania zawartości strony, czekając na wczytanie wszystkich skryptów.

Serwer i PHP

Akcelerator PHP

Drupal, jak wiadomo, korzysta z PHP. Wpływ tak zwanych „akceleratorów” na wydajność skryptów PHP jest niemały. Podczas swoich testów, Dries Buytaert, twórca Drupala, stwierdził czterokrotny wzrost wydajności po włączeniu akceleratora APC. Jak to zazwyczaj w przypadku Drupala bywa, największy wzrost wydajności dotyczył anonimowych (niezalogowanych) odwiedzających.

APC można nawet czasem zainstalować na serwerach „wirtualnych”, czyli shared hosting, oczywiście o ile ten lub inny akcelerator nie jest już aktywny. Tak jest właśnie w przypadku DreamHost (którego usług już nie polecam). W internecie znaleźć można instrukcję instalacji APC na DreamHost. Wiele serwerów korzysta też z konkurencyjnego rozwiązania, eAccelertor, które ma opinię wydajniejszego (Benchmarking APC vs. eAccelerator using Drupal).

Do zainstalowania akceleratora potrzebujemy dwóch rzeczy – możliwości kompilowania programów i dostępu do pliku konfiguracyjnego PHP, php.ini.

W witrynie 2bits znajdziemy instrukcję instalacji APC i eAccelerator na Ubuntu.

Inne kwestie dotyczące PHP

PHP 5 jest nieco wolniejsze od PHP 4. „Nieco” w przypadku bardzo popularnych witryn może mieć jednak znaczenie.

FastCGI, ze względu na bezpieczeństwo stosowane zazwyczaj w przypadku serwerów, do których dostęp ma wielu administratorów witryn, jest niestety wolniejsze niż mod_php, standardowy sposób uruchamiania PHP na serwerach linuksowych.

Serwer HTTP

Świat nie kończy się na Apache. Lighttpd jest prawie dwa razy szybszy, a Drupal podobno i z niego będzie zadowolony.

Pamięć podręczna – idziemy dalej

Więcej pod ręką!

Nie wszystkie elementy witryny są objęte mechanizmem pamięci podręcznej. Stara się temu zaradzić moduł Advanced cache, przeznaczony dla Drupala 5. Drupal 6 wykorzystuje niektóre z jego rozwiązań, np. pamięć podręczną dla bloków. Advanced cache nie jest do końca modułem, a właściwie zbiorem „łat” na Drupala 5.

Pamięć podręczna Drupala – rozwiązania alternatywne

Są jednak całkiem inne mechanizmy pamięci podręcznej, alternatywne w stosunku do standardowego drupalowego rozwiązania. Zazwyczaj pomagają one pozbyć się sporej ilości zapytań, które Drupal kieruje do bazy danych podczas korzystania z pamięci podręcznej.

Moduł APC – Alternative PHP Cache, korzystając ze wspomnianego wcześniej APC (musi być zainstalowane na serwerze), zastępuje zwykłą pamięć podręczną Drupala, korzystając z wydajniejszej pamięci operacyjnej serwera. Podczas instalacji należy pamiętać o umieszczeniu odpowiedniego kodu (podany na stronie modułu) w pliku settings.php witryny.

Bardzo ciekawym pomysłem jest Boost. Moduł tworzy statyczne kopie wygenerowanych przez Drupala stron. Korzyści wynikającego z jego korzystania mogą być ogromne. Wyobraźmy sobie tylko, jak spada ilość zapytań do bazy danych. Niestety, jego stosowanie ma sens tylko w przypadku niektórych witryn – tych mało „dynamicznych”, na których rzadko pojawiają się odpowiedzi. Więcej informacji w blogu Arto Bendikena.

Kolejny moduł, fastpath_fscache, zapisuje pamięć podręczną na dysku. Od dawna nie był aktualizowany i nie jest zbyt popularny, choć niektóre głosy zdają się potwierdzać korzyści płynące ze stosowania „plikowej” pamięci podręcznej.

Pamięć podręczna zapytań do bazy danych

Moduł QueryCache umożliwia zapisywanie zapytań do bazy danych do pamięci podręcznej. Niektóre z tabel bazy danych rzadko są bowiem modyfikowane. Moduł kierowany jest przede wszystkim do bardzo popularnych witryn.

Elementy witryny

Ach ta wyszukiwarka

Jednym z najbardziej zasobożernych elementów witryny jest wyszukiwarka (znów baza danych). W Drupalu 6 poczyniono pewne kroki zmierzające do polepszenia wydajności wbudowanego modułu Search, niektórzy twórcy Drupala chcą jednak pójść dalej – Document search module design.

Co można zrobić na własną rękę? Cóż, wyłączyć moduł i skorzystać z innych, opisywanych już na łamach Drupal Polska systemów wyszukiwania.

Elementy zbyt „dynamiczne”

Zbiór cytatów, z którego za każdym wyświetleniem strony wybierany jest jeden, to dobry pomysł na zniwelowanie pozytywnych efektów korzystania z mechanizmu pamięci podręcznej (w praktyce na takich stronach ona nie istnieje).

Podobnie rzecz ma się z innymi elementami witryny, które zmieniają się za każdym wyświetleniem strony. Dlatego zaleca się między innymi umieszczenie formularza dodawania odpowiedzi na osobnej stronie (ustawienie można znaleźć na podstronie /admin/content/comment/settings w przypadku Drupala 5 i podstronach /admin/content/types/page danych rodzajów zawartości w Drupalu 6).

Moduły dodatkowe a cron

Jeśli to tylko możliwe, należy nakazać modułom dodatkowym, takim jak Subscriptions, wykonywanie swoich czynności podczas uruchamiania zadań cron. Zmniejsza to wpływ dużej liczby zapytań kierowanych przez moduły do bazy danych.

Nieistniejące strony (404)

Już Lao Tsy uczył o istotności tego, co nie istnieje. Potwierdza się ona i w przypadku Drupala, w każdym razie jego standardowej konfiguracji ;) . W wypadku żądania nieistniejącej strony, by wyświetlić komunikat Nie znaleziono strony (a więc komunikat o błędzie 404) ładowane są prawie wszystkie elementy witryny (nagłówek, logo, pliki graficzne, arkusze stylów, skrypty JS itd.). Cóż z tego – zapytacie. Zdarza się, że popularną witrynę upatrzą sobie roboty cierpliwie szukające luk w zabezpieczeniach (m.in. stron dostępu). Niepotrzebnie wykorzystują więc one zasoby serwera.

Zmiana opisanego zachowania Drupala jest bardzo prosta. Wystarczy linijkę ErrorDocument 404 /index.php z pliku .htaccess z głównego katalogu witryny zamienić na ErrorDocument 404 /404.htm, a także w tym samym katalogu umieścić plik 404.htm z nowym, mniej przyozdobionym, komunikatem o nieznalezieniu strony:

<html>
<head><title>Nie znaleziono strony</title>
<body>
<h1>Nie znaleziono strony</h1>
<p>Żądana strona nie została znaleziona. Możesz przejść na <a href="/">główną stronę witryny</a>.
</body>
</html>

Podsumowanie

Co powinien zrobić administrator popularnej witryny przeżywającej problemy z wydajnością? Przede wszystkim zastanowić się nad kupnem serwera dedykowanego, zmienić sposób wyszukiwania treści, upewnić się, że serwer korzysta z akceleratora PHP, a także rozważyć zmianę serwera HTTP.

Inne zasoby

Spora liczba artykułów dotyczących wydajności Drupala znajduje się w witrynie 2bits. Odsyłam również do artykułu, w którym Dries Buytaert opisał swoje testy dotyczące różnych konfiguracji serwerów.

Odpowiedz

Advanced cache

gaweł (niezweryfikowany), sob., 2008-05-03 16:51

Odpowiedz

Nie do końca się zgodzę z tym advanced cache. Używałem tego moduły i w połączeniu z APC spowalniał ładowanie strony o ca. 30% w porównaniu oczywiście z brakiem tego modułu i włączonym APC. Porównanie robiłem dla niezalogowanego usera – co pewnie duużo zmienia.