Nie tak dawno stworzyłem wpis z opisem optymalizacji serwera apache pod kątem popularnego oprogramowania blogowego – platformy wordpress. Jakby nie patrzeć, apache jest tylko jednym z wielu ogniw wpływających na szybkość serwowania stron. Wspomniany wyżej kombajn korzysta z bazy danych MySQL, często zasypując ją skomplikowanymi zapytaniami. Im więcej zapytań do bazy (np. godziny szczytu, lub duża ilość słabo zoptymalizowanych pluginów) tym bardziej uciążliwe (wolniejsze) będzie przeskakiwanie między stronami serwowanego bloga.
Jak można wzmocnić ten trybik machiny? Jak to zwykle bywa, lepiej „zapobiegać niż leczyć” – nie warto instalować miliona niepotrzebnych wodotrysków. Jeśli koniecznie potrzebujemy jakąś wtyczkę, to lepiej unikać wypocin niedoświadczonych programistów – zmniejszy się ryzyko niezoptymalizowanych zapytań do bazy. Zawsze można pokusić się o samodzielną optymalizację kodu instalowanych wtyczek… Niestety stosowanie się do powyższych zasad i tak zwykle nie wystarczy w przypadku dużej popularności bloga. Zanim nadejdą tłumy czytelników warto zdecydować się na jeden z prostszych tricków – uruchomienie mechanizmu cache bazy danych MySQL.
Aby uruchomić mechanizm cache bazy danych w sekcji konfiguracyjnej [mysqld] pliku /etc/my.cnf dodajemy dwie zmienne:
query_cache_type=1 query_cache_size=8M
W ten sposób przeznaczamy 8M pamięci na cache.
Od teraz większość zapytań do bazy zostanie przetworzona raz, a wynik każdego z osobna zostanie zapisany w pamięci podręcznej bazy. W przypadku ponownego pojawienia się tego samego zapytania serwer MySQL zamiast od nowa przetwarzać formułkę wczyta wynik z pamięci. Pozwala to na zaoszczędzenie mocy obliczeniowej procesora oraz znaczne obniżenie czasu odpowiedzi. Oczywiście, jeśli któraś z odpytywanych tabel zostanie zmieniona, to kopia wyniku przechowywana w pamięci cache także zostanie zaktualizowana.
Czy 8M pamięci cache to dużo? Czy może zbyt mało? Nie da się jednoznacznie odpowiedzieć na to pytanie – wszystko zależy od tego jak duży jest blog, z ilu pluginów/widgetów korzysta itd. Ilość pamięci najlepiej dobrać doświadczalnie – MySQL zezwala na wgląd statystyki (ilość zapisanych odpytań bazy, ilość wolnej pamięci, ilość trafień, częstość korzystania z wyszukiwarki, ilości słów kluczowych, kategorii itd) wykorzystania cache prostym zapytaniem:
SHOW STATUS LIKE '%qcache%';
Zaraz po przeładowaniu konfiguracji mysql:
mysql> SHOW STATUS LIKE '%qcache%'; +-------------------------+---------+ | Variable_name | Value | +-------------------------+---------+ | Qcache_free_blocks | 1 | | Qcache_free_memory | 8379864 | | Qcache_hits | 0 | | Qcache_inserts | 0 | | Qcache_lowmem_prunes | 0 | | Qcache_not_cached | 1 | | Qcache_queries_in_cache | 0 | | Qcache_total_blocks | 1 | +-------------------------+---------+ 8 rows in set (0.00 sec)
Kilka godzin później:
mysql> SHOW STATUS LIKE '%qcache%'; +-------------------------+---------+ | Variable_name | Value | +-------------------------+---------+ | Qcache_free_blocks | 33 | | Qcache_free_memory | 8012064 | | Qcache_hits | 5992 | | Qcache_inserts | 753 | | Qcache_lowmem_prunes | 0 | | Qcache_not_cached | 724 | | Qcache_queries_in_cache | 200 | | Qcache_total_blocks | 444 | +-------------------------+---------+ 8 rows in set (0.01 sec)
Jak widać zostało sporo wolnej pamięci, a mysql został odciążony od przetwarzania starych zapytań ponad 5000 razy (analytics podał zaledwie kilkadziesiąt unikalnych wizyt od momentu uruchomienia cache mojego bloga do momentu drugiego pomiaru).
Czy uruchomienie cache mysql zapewni wystarczającą ochronę przed nalotami użytkowników z głównych stron serwisów popularnych tak jak wykop.pl? Kilka tysięcy odsłon w krótkim czasie nadal będzie zbyt dużym obciążeniem dla atomowego serwerka – zoptymalizowanie apache i cacheowanie w mysql nie wystarczy. Skuteczną metodę pozwalająca obsłużyć tłumy czytelników bez przeciążania niezbyt tęgiej maszynki opiszę dopiero za jakiś czas…