Optymalizacja serwera dla Drupala z wynikami pomiarów

  1. Zamiast przedmowy
  2. Model eksperymentalny
  3. Sprzęt eksperymentalny
  4. Dane serwera surowego
  5. Optymalizacja PHP
  6. Optymalizacja MySQL
  7. Testy LoadImpact
  8. Zamiast zawarcia

Sam w sobie instrukcje, gdzie można coś ulepszyć na serwerze, aby Drupal mógł działać szybciej, można znaleźć w Internecie w różnym stopniu szczegółowości. Jednak wszystkie artykuły, które napotkałem, miały niewielką wadę: nie natrafiłem na żadne rzeczywiste pomiary, które towarzyszyły temu ustawieniu. Jak numerycznie zmienia się szybkość generowania strony? Jak zmienia się wykorzystanie pamięci? Co się dzieje, gdy liczba równoległych zapytań wzrasta? Zróbmy eksperyment. Niektóre zalecenia przedstawione w tym artykule mają charakter ogólny i mogą być przydatne dla innych systemów CMS.

Zamiast przedmowy

Ten artykuł opiera się na wyborze materiałów. Uwagi dotyczące dostrajania serwera opublikowane na oficjalnej stronie Drupala. Na tej podstawie wybiera najbardziej uniwersalny charakter i może być zastosowany do dowolnego serwera, na którym ma być używany Drupal (w szczególności sekcje dotyczące konfiguracji PHP i MySQL). Ten artykuł nie obejmuje dostrajania samego CMS.

Model eksperymentalny

Aby sprawdzić obciążenie, utworzono pewną standardową ciężką stronę. W tym celu wykorzystano Drupal 7 i kilka popularnych modułów, w tym Widoki i Pathauto. Do jednego z typów materiałów dodano pole numeryczne, które mogło przyjmować wartość od 1 do 10. Korzystając z funkcji generowania treści modułu Devel, utworzono około 10 tysięcy stron tego typu materiałów i od 0 do 15 komentarzy do każdego postu.

Następnie utworzono blok Widoki i umieszczono go na stronie głównej, wybierając 100 losowych stron, gdzie pole miało wartość 5 (to znaczy, zgodnie z teorią prawdopodobieństwa, 100 na 1000 stron) wraz z komentarzami do nich. Globalny: Zastosowano losowe kryteria filtrowania, aby zagwarantować, że strona zostanie ponownie wygenerowana przy każdym ładowaniu. Na osobistym serwerze testowym czas generowania takiej strony wynosił około 10 sekund. Podczas przygotowań powstał testowy sklep internetowy oparty na Commerce Kickstarter i wygenerowano około 5 tys. Produktów. Okazało się jednak, że Global: Random nie jest wcale przyjazny dla API wyszukiwania, a bez randomizacji strona z 96 produktami jest ładowana znacznie szybciej niż poprzednia strona testowa. Dlatego też nie przeprowadzono pomiarów prędkości sklepu internetowego. Witryny testowe zostały przeniesione do ...

Sprzęt eksperymentalny

Do eksperymentów pożyczyłem świeżo zainstalowany przez kilka dni. VPS Intel Xeon E3-1230 3,2 GHz / 2-3 GB RAM / 30 GB SSD i Intel Xeon E3-1230 / 8 GB DDR3 / 4x1TB SATA2 / 100Mbps Unmetered w Holandii (zwanych dalej odpowiednio VPS i E3-1230). Serwery zostały skonfigurowane LAMP + Nginx. Główna część pomiarów została wykonana przez narzędzie. ab łącznie 1000 żądań i szereg równoległych żądań od 10 do 50. Na koniec uruchomiono również kilka testów Loadimpact.

Dane serwera surowego

Pierwszy pomiar został wykonany przed rozpoczęciem jakiejkolwiek optymalizacji. Właściwie w tych pomiarach zatrzymałem się przy 40 równoległych zapytaniach. Wyniki wyglądają tak:

Na tym i kolejnych podobnych wykresach na osi X będzie udział żądań, które były podawane w czasie nieprzekraczającym odpowiedniej wartości na osi Y
Na tym i kolejnych podobnych wykresach na osi X będzie udział żądań, które były podawane w czasie nieprzekraczającym odpowiedniej wartości na osi Y.

Ponadto, ze względu na zainteresowanie, uruchomiłem bezpłatny test Loadimpact, ale nie stworzył on żadnego znaczącego obciążenia.

Optymalizacja PHP

Pierwszą rzeczą do zrobienia na serwerze pod Drupalem jest ustawienie wartości memory_limit na co najmniej 256M w php.ini. Z reguły jest to wystarczające dla większości witryn. Ale czasami 128M to za mało. Nie można tego jednak nazwać optymalizacją, jest to raczej niezbędna konieczność.

Aby przyspieszyć witryny na poziomie PHP, programiści zalecają stosowanie różnych optymalizatorów buforowania. W innych źródłach najczęściej wspomina się o APC, ponieważ zwróciłem się do niego. Jak to ująć, możesz przeczytać instrukcje . Teraz jesteśmy zainteresowani kluczowymi ustawieniami. Właściwie głównym parametrem jest rozmiar segmentu pamięci podręcznej, apc.shm_size. Im cięższa strona, tym więcej różnych plików połączonych podczas wykonywania, tym większa powinna być wartość. Na przykład 64M wystarczyło na stronę testową. A sklep testowy o tej wartości dał błąd:

[Pn 13 stycznia 21:41:46 2014] [błąd] [klient 176.36.31.190] Ostrzeżenie PHP: Nieznany: nie można przydzielić pamięci dla puli. w Nieznany w linii 0, referer: http://s2shop.1b1.info/products?page=2

Podniesienie wartości do 256M w jednej chwili usunęło ten problem. Zgodnie z modułem Devel, w przypadku jednorazowych widoków witryn włączenie buforowania miało wpływ na następujące parametry:

  • czas generowania strony został skrócony o połowę do dwóch razy;
  • Maksymalne zużycie pamięci zostało zmniejszone z około 50-55 MB do 30-32 MB w przypadku witryny testowej i od około 65-70 MB do 30-32 MB w przypadku magazynu testowego.

Jak włączenie APC wpłynęło na wyniki bombardowania ab będzie omówione nieco później. Zgodnie z publicznie dostępnymi informacjami publicznymi, używanie php-fpm zamiast Apache + mod_php daje doskonałe wyniki. Jednak nie próbowałem jeszcze porównywać tych dwóch konfiguracji.

Optymalizacja MySQL

Jednym z najłatwiejszych sposobów optymalizacji MySQL jest zastąpienie my.cnf my-huge.cnf. Ten plik jest przeznaczony dla systemów z wystarczającą ilością pamięci RAM (2 GB lub więcej) i wykorzystaniem MySQL na dużą skalę. Między innymi różni się od standardowej konfiguracji znacznie większym rozmiarem bufora (key_buffer_size) i włączeniem buforowania zapytań (query_cache_size).

Ogólna zmiana szybkości odrzutu dla sekwencyjnego użycia wygląda następująco.

E3-1230, 10 równoległych żądań
E3-1230, 10 równoległych żądań

VPS, 10 równoległych żądań
VPS, 10 równoległych żądań

E3-1230, 30 równoległych żądań
E3-1230, 30 równoległych żądań

VPS, 30 równoległych żądań
VPS, 30 równoległych żądań

Jak widać, różnica między niezoptymalizowanym MySQL i zoptymalizowanym jest bardziej zauważalna na VPS niż na E3-1230. Ośmielę się zasugerować, że wynika to z używania dysków SSD w VPS. Obecnie konfiguracje serwerów, w których bazy danych są umieszczane na dyskach SSD, stają się coraz bardziej popularne. Biorąc pod uwagę, jak bardzo spadły one ostatnio w cenie, taka decyzja nie pozwala na mocne uderzenie iw wielu przypadkach umożliwia znaczne przyspieszenie działania witryn. Zaletą SSD są, moim zdaniem, dwie następujące grafiki.

E3-1230, 50 równoległych zapytań
E3-1230, 50 równoległych zapytań

VPS, 50 równoległych żądań
VPS, 50 równoległych żądań

Jak widać, na serwerze z dyskami SATA buforowanie z buforowaniem zaczyna się bardzo szybko dławić. W tym samym czasie na VPS z dyskami SSD utrzymuje się ogólna tendencja. W VPS starałem się jeszcze bardziej zwiększyć wartości key_buffer_size i query_cache_size, więc otrzymałem niewielki, ale stabilny wzrost wydajności (krzywa MySQL 2). Jednak na tym etapie w obu konfiguracjach procesor już zaczyna się dławić.

Jednak na tym etapie w obu konfiguracjach procesor już zaczyna się dławić

Testy LoadImpact

Testy przeprowadzone za pomocą narzędzia ab nie pokazują rzeczywistego ładowania stron witryny, ale raczej jakościową zmianę wydajności. Aby niektóre dane były bliższe życiu, wykorzystałem kilka testów Loadimpact .

  1. Główna strona witryny testowej została ustawiona na maksymalnie 100 SBU, mniej więcej równomiernie rozmieszczonych w 5 różnych lokalizacjach (2 w USA, 2 w Europie, 1 w Australii). Całkowity harmonogram nie pozwala sprawdzić, czy serwer obciążył to obciążenie przynajmniej trochę.

    Całkowity harmonogram nie pozwala sprawdzić, czy serwer obciążył to obciążenie przynajmniej trochę

    Ale wzrost obciążenia staje się bardziej zauważalny, jeśli spojrzysz na wykresy szczególnie dla punktów europejskich, z którymi łączność jest lepsza.

    Ale wzrost obciążenia staje się bardziej zauważalny, jeśli spojrzysz na wykresy szczególnie dla punktów europejskich, z którymi łączność jest lepsza

    Jednocześnie całkowity przepływ danych był bliski 90 Mb / s. Chciałem dogonić kanał na półkę, ale nie było już żadnych kredytów.

    Chciałem dogonić kanał na półkę, ale nie było już żadnych kredytów

    Obciążenie procesora staje się zauważalne, jednak średnia obciążenia nie idzie do żadnego porównania z testami ab.

    Obciążenie procesora staje się zauważalne, jednak średnia obciążenia nie idzie do żadnego porównania z testami ab

  2. Podsumowując, skłoniłem zwykłą SDL małej informacji i ustawiłem Loadimpact z 8 różnych punktów. Wszystkie punkty testowe uzyskały dostęp do różnych stron witryny. W ciągu 10 minut liczba SBU również osiągnęła 100.

    W ciągu 10 minut liczba SBU również osiągnęła 100

    Wypłata była bardzo wyrównana, bez widocznego spowolnienia.

    Wypłata była bardzo wyrównana, bez widocznego spowolnienia

    W tym samym czasie serwer tego testu prawie nie zauważył.

    W tym samym czasie serwer tego testu prawie nie zauważył

Zamiast zawarcia

Uważałem, że wpływ na szybkość witryny ma tylko dwa istotne parametry, ponieważ będę wdzięczny każdemu, kto może udzielić dodatkowych przydatnych wskazówek na ten temat. Ponadto, gdzieś 5 dni po publikacji, środowiska testowe będą nadal żywe, a jeśli masz inne zalecenia optymalizacyjne lub propozycje testowania, spróbuję je ożywić i dodać do artykułu w tym okresie. Wzywam wszystkich do dzielenia się własnymi doświadczeniami optymalizacji i ich sztuczkami. I dziękuję za cierpliwe czytanie.

Jak numerycznie zmienia się szybkość generowania strony?
Jak zmienia się wykorzystanie pamięci?
Co się dzieje, gdy liczba równoległych zapytań wzrasta?
1.info/products?