Rzeczywiste doświadczenie w skalowaniu i dostrajaniu wydajności

Witryna, nad którą pracuję, prawdopodobnie wkrótce uzyska dużą popularność . Klient mówi o możliwości około 2500 trafień na sekundę w ciągu około jednego dnia.

Ignorując fakt, że ten wskaźnik trafień jest prawdopodobnie dzikim optymizmem klienta i oprócz uzyskania jak największej liczby serwerów, jaki jest najlepszy sposób skonfigurowania Drupala do obsługi dużego wskaźnika trafień.

Czytałem Skalowanie infrastruktury Drupal.org , Drupal wydajności bloga , Best Practices dla Skalowanie Drupal i wiele innych stron, ale co szukam jest prawdziwe doświadczenie robi to, co działa, a co nie, i co oczekiwać.

Odpowiedź Markdorisona jest w zasadzie przyjętą metodą ataku na ten problem. Zajmę się tym trochę dalej.

Kiedy masz Pressflow dla D6 lub Drupal dla D7, Memcached i Lakier działają dobrze razem, musisz dostosować kod pliku VCL . Dostępne są darmowe, które tworzą punkty początkowe, ale zawsze musisz się nimi bawić.

Aby Varnish działał optymalnie, upewnij się, że uruchamiasz go z -s malloc xG zamiast domyślnego -s file / path / to / file. Również w przypadku lakieru przechowuj statyczne przedmioty w pamięci podręcznej lakieru tak długo, jak możesz.

Jeśli masz więcej niż jeden serwer WWW, usuń ETag z nagłówka wysłanego do Varnish w VCL. Usuwam także Expires i po prostu polegam na Wiek i maksymalny wiek w nagłówkach, aby przeglądarki mogły wrócić do strony.

Wersja 1.5 (od 3 marca 2011 r.) Jest wciąż najszybszą wersją modułu Memcached od Drupal.org. Zwykle wdrażam go za pomocą jednego pojemnika na serwer, aby obniżyć ruch TCP dla połączeń z wieloma pojemnikami na dużą skalę)

Skonfiguruj buforowanie w „Wydajności” na zewnętrzne i ustaw maksymalny wiek, który wyśle ​​prawidłowe nagłówki do buforującego serwera proxy, takiego jak Varnish.

Jeśli nie możesz uzyskać poprawnego buforowania niektórych stron w programie Varnish, sprawdź posty na blogu w Internecie, które szczegółowo opisują sposób sprawdzania żądań. Oto przykładowy post, który napisałem jakiś czas temu: Co powstrzymuje Varnish i Drupal Pressflow przed buforowaniem wyświetleń stron anonimowych użytkowników

Powinieneś wybrać InnoDB (lub jedną z jego nazw innych dostawców, takich jak XtraDB) dla MySQL i przenieść do niego wszystkie tabele. Następnie sprawdź ten post na blogu, aby uzyskać podstawowe porady dotyczące tuningu http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

Posiadanie dużej puli buforów jest fundamentalnie ważne. Podczas testowania strony włącz dziennik powolnych zapytań. Prawdopodobnie chcesz najpierw przechwytywać zapytania trwające dłużej niż 50 ms, a następnie dostroić je i powtarzalnie skracać czas powolnego przechwytywania dziennika, dopóki większość zapytań nie będzie działać przy użyciu indeksów i działa dość szybko.

Inne podstawy obejmują posiadanie APC dla PHP. Jeśli wybierasz szybki CGI zamiast mod_php, poświęć trochę czasu na udostępnienie pamięci podręcznej APC między instancjami php, konfigurując dobry skrypt opakowujący. Upewnij się również, że pamięć podręczna APC znajduje się w pliku odwzorowanym w pamięci, aby wycisnąć każdy ostatni fragment PHP.

Poleciłbym zacząć od Pressflow (jeśli używasz Drupala 6), Memcache , Varnish i jakiejś formy sieci dystrybucji treści (CDN), takiej jak Akamai. Efektem końcowym powinno być jak najmniejszej liczby tych użytkowników, którzy faktycznie uderzą w serwer pochodzenia.

Jeśli masz części strony, których nie jesteś w stanie buforować dla nieanonimowych użytkowników (rzeczy specyficzne dla tego użytkownika, „Welcome userX” itp.), Możesz zbadać opcje zapełniania tych części strony, takie jak asynchroniczne obejmuje wywołania zwrotne lub boczne.

Jeśli masz mniejszą grupę użytkowników wewnętrznych (np. Grupę redaktorów), którzy muszą mieć możliwość przeglądania niebuforowanej wersji witryny, zalecam udostępnienie niebuforowanej wersji witryny pod innym adresem URL (chronionym za VPN lub równoważne, jeśli to możliwe).

2500 wyświetleń na sekundę w ciągu dnia - jeśli „trafienie” oznacza „dostarczoną stronę”, to 216 milionów stron dziennie. Pozwól, że ci powiem: nie masz 216 milionów stron dziennie. Uwielbiam tych klientów ...

To powiedziawszy, nieprzetworzone dane o ruchu nic nie mówią. Podczas gdy porady w tym wątku brzmią dobrze na temat Varnish / CDN, jeśli wszystko, co masz, to anonimowy ruch, ale jeśli zalogowałeś się, stoisz przed wyzwaniem. Ale zanim poświęcisz bezbożną ilość czasu i wysiłku na rozwiązanie problemu, upewnij się, że masz problem. 2500 trafień na sekundę, bing dostaje mniej niż to, zdajesz sobie sprawę, prawda?

• Po stronie serwera

  • Zainstaluj lakier do buforowania stron dla anonimowych użytkowników.
  • Zainstaluj trwały system pamięci podręcznej (Memcached, APC, Memcache).
  • Użyj CDN, takiego jak Akamai, do obsługi plików statycznych (JavaScript, CSS, obrazy).

• Strona kodowa

  • Użyj Pressflow, pozwala Varnish wyświetlać stronę w pamięci podręcznej dla anonimowych użytkowników.
  • Oczyść stół strażniczy Drupala. Za każdym razem, gdy rejestrowany jest błąd watchdoga, zużywa zasoby procesora na serwerze WWW i serwerze bazy danych. Znacząco wydłuża czas ładowania.
  • Wdrażaj statyczne i trwałe strategie pamięci podręcznej, dopóki wolny dziennik zapytań nie pojawi się w czystości.
  • Za wszelką cenę unikaj błędów PHP występujących w zagnieżdżonych pętlach foreach.
  • Odinstaluj nieużywane moduły.
  • Włącz buforowanie bloków rdzenia i widoków Drupala.

• Baza danych

  • Upewnij się, że tabele są odpowiednio indeksowane w celu szybszego wyszukiwania.
  • Nie przechowuj niepotrzebnych rekordów, dostęp do bazy danych 100 węzłów będzie zawsze możliwy szybciej niż baza danych 3 milionów węzłów.

Chciałbym również posłuchać tego podcastu Lullabot o tym, jak założyli witrynę Grammys.com w celu wybuchu ruchu w ciągu tygodnia. To było całkiem pouczające wyjaśnienie.

http://www.lullabot.com/podcasts/podcast-92-grammycom

Chociaż bardzo trudno jest przewidzieć wzorce, jeśli masz dobre pojęcie o natężeniu ruchu. Załaduj przetestuj swoje rozwiązanie. Istnieje wiele różnych opcji i wiele nie będzie można przewidzieć, dopóki nie pojawi się ruch na żywo, ale jeśli załadujesz test tak dużo, jak to możliwe, przynajmniej będziesz mieć dość pewności, że Twoja konfiguracja poradzi sobie z ruchem.

Całe strojenie na świecie nie pomoże, jeśli nie przetestujesz go najpierw.

To była prezentacja w DC SF o tym, jak zrobił to ekonomista. http://sf2010.drupal.org/conference/sessions/performance-testing-economist-online-using-grinder

W przypadku witryn o dużym natężeniu ruchu należy używać wielu serwerów i modułu równoważenia obciążenia lub po prostu CDN. Bardzo ważne jest także buforowanie tak dużo, jak to możliwe, aby zminimalizować obciążenie serwerów WWW.

Korzystanie z sieci dostarczania treści ( CDN ) pomaga rozłożyć zasoby na kilka domen (dzielenie domen), co zmniejsza obciążenie serwera WWW.

Korzystanie z CDN pomaga w rozproszonym buforowaniu i zdalnym przyspieszaniu, a także pomaga złagodzić ataki DDoS z powodu wielu punktów końcowych. Pomaga w bezpieczeństwie, ponieważ trudniej jest wykorzystać buforowaną zawartość.

Przykładowi dostawcy: Fastly , Rackspace , Akamai , Azure, CloudFlare, Amazon, MaxCDN, Verizon.

Oto kilka sugestii:

• W przypadku CDN używaj domen bez plików cookie dla buforowanych komponentów statycznych (takich jak sstatic.net ). Ponieważ niektóre serwery proxy mogą odmówić buforowania komponentów żądanych za pomocą plików cookie.
• Ogrzej pamięć podręczną po wyczyszczeniu pamięci podręcznej (za pomocą wget, Cache Warmer , Drush ECL ).
• Użyj monitorowania wydajności (np. New Relic lub Yottaa, które mają integrację z Drupal).
• Użyj narzędzia do monitorowania swojej witryny (np. Nagios).
• Zainstaluj moduł integracji lakieru i lakieru HTTP Accelerator , a następnie skonfiguruj go .
• Lakier + Authcache: sprawdź ten przykładowy plik VCL dla pliku konfiguracyjnego lakieru Authcache .
• Rozważ funt lub NGINX przed lakierem . Zobacz: Dlaczego Funt jest niesamowity przed Lakierem .
• NGINX może działać jako odwrotny serwer proxy i moduł równoważenia obciążenia, więc może zastąpić funt i lakier.
• Rozważ komercyjną wersję Varnish lub NGINX, aby wykorzystać funkcje niedostępne w wersji „open source” dla społeczności.
• Rozważ sprzętowe równoważenie obciążenia / buforowanie, aby zastąpić lakier i funt (np. BIG-IP F5 ).
• Skorzystaj z narzędzi takich jak abJMeter dla TTFB , obciążenia i testów warunków skrajnych w swojej aplikacji internetowej.

Twoja architektura internetowa z punktu widzenia użytkownika może wyglądać następująco:

1. Użytkownik (buforowanie lokalnej przeglądarki).
2. NGINX lub Pound + Varnish (moduł równoważenia obciążenia, odwrotne proxy jako akcelerator HTTP).
3. Apache (serwer WWW).
4. PHP-FPM (PHP FastCGI Process Manager).
5. MariaDB (baza danych).

Aby uzyskać sugestię dotyczącą optymalizacji Drupala, sprawdź: Jak poprawić wydajność Drupala?

Włącz dwa rozszerzenia:

• Zend OPcache
• Wincache

Twoja wydajność będzie działać lepiej.

Jeśli chcesz przekręcić Zend OPcache i Wincache na Microsoft Azure, najpierw utwórz nazwę folderu ini„pod D:\home\site\”. Ponadto utwórz 2 pliki .user.ini”i„ settings.ini”

Dodaj następującą konfigurację do każdego pliku:

.user.ini

[PHP]
post_max_size = 32M
memory_limit = 512M
zend.enable_gc = On
upload_max_filesize = 32M
opcache.enable=1

setting.ini

wincache.ocenabled = 1
wincache.ocachesize = 255

Dodaj także ustawienie aplikacji do swojej aplikacji internetowej za pomocą klucza PHP_INI_SCAN_DIR i wartości d:\home\site\ini

Po zmianie PHP_INI_SYSTEM uruchom ponownie aplikację internetową. Jeśli chcesz dowiedzieć się więcej o konfiguracji twigging, sprawdź dokumentację Microsoft .

Po powyższym ustawieniu moja witryna Drupal (Drupal 8.3) ładuje się w ciągu 3 sekund.

Można również zbadać redystrybucję obciążenia na wiele serwerów przy pomocy rozwiązania równoważącego obciążenie oparte na DNS lub oprogramowaniu / sprzęcie. Spowodowałoby to również odporność na uszkodzenia.