Który serwer MySQL zapewnia lepszą wydajność Magento

Czego używasz jako serwera MySQL dla Magento?

• MySQL (Oracle)
• Perkona
• inne (MariaDB)

Percona zapewnia zestaw ulepszeń dla pamięci InnoDB używanej intensywnie przez Magento, ale te ulepszenia mają znaczenie podczas prowadzenia sklepu Magento.

Jak poprawić wydajność (ogólne podejście do architektury, a nie szczegółowe informacje o ustawianiu określonych zmiennych, itp innodb_flush_log_at_trx_commit=2.). Wiem, że NBS próbowało replikacji master-master, ale to nie jest stabilne.

Wystąpiły pewne problemy z replikacją master-slave z odczytami przekierowanymi w stronę slave, ponieważ wystąpiły pewne opóźnienia w replikacji danych.

Wyprowadzasz się z MySQL w jak największym stopniu? (szukaj solr i tak dalej).

Wchodzisz w szeroki, szeroki świat optymalizacji i na pewno nie ma jednego uniwersalnego podejścia.

Zdefiniuj wydajność

Czy masz na myśli czas wczytywania strony dla jednego użytkownika, czy ogólną pojemność / całkowitą współbieżność? Oba są bardzo wyraźnie różne - i nie są ściśle powiązane. Całkowicie możliwe jest posiadanie szybkiego sklepu o ograniczonej pojemności; lub wolny sklep z dużą ilością miejsca.

Dlatego zajmując się każdym rodzajem wydajności:

1. Czas ładowania strony postrzegany przez jednego użytkownika
2. Całkowita pojemność / współbieżność

Musisz rozwiązać każdy niezależnie, korzystając z własnych rozwiązań - zwłaszcza, że ​​każdy ma swoje własne wąskie gardła.

Załóżmy, że masz kompetentnego hosta, który już skonfigurował inne aspekty twojego serwera optymalnie dla twojego sklepu.

Czas ładowania strony postrzegany przez jednego użytkownika

Czy MySQL jest wąskim gardłem
Nie. Nie bezpośrednio. Chodzi o opóźnienie, w większości przypadków podczas testowania czasu wczytywania strony - trafią tylko pamięci podręczne. Kluczem jest tutaj zminimalizowanie opóźnień.

• Dostosuj odpowiednio rozmiary pamięci podręcznej MySQL (nie ma właściwej odpowiedzi, dostosowujemy ustawienia zupełnie inaczej, miesięcznie, dla sklepu)
• Zmniejszyć opóźnienie sieci. Dla ramek 64-bajtowych; 51,2µs dla 10 Mbps, 5,12µs dla 100 Mbps i 4,096µs dla 1 Gbps. Daje to poprawę o 20% poprzez przejście z 100 Mb / s do 1 Gb / s. ^s1
• Zwiększ pojemność sieci. Byłbyś zaskoczony, że wiele megabajtów na sekundę jest wymienianych między Internetem a serwerem DB, zwykle przekraczającym 10 MB / s - więc wymagane jest minimum 100 Mb / s ^s1 . Lub po prostu przenieś serwer DB lokalnie.
• Korzystanie z SOLR. Silniki zewnętrzne są czasem lepiej przystosowane, SOLR z pewnością jest szybszy dla większych katalogów (i podkreślę, większe katalogi ). Nawet nie dostrojony SOLR będzie generował warstwowe wyniki nawigacji i wyniki wyszukiwania szybciej niż MySQL.

Ale te zmiany będą miały tak niewielki wpływ na czas ładowania strony - tam gdzie wąskie gardło jest naprawdę gdzie indziej.

• Dostrój aplikację. Magento ma kilka dość dużych błędów w sposobie budowania kolekcji i buforowania ich; natknęliśmy się na wiele poważnych problemów z kodem, które mogą obniżyć wydajność. W kilku przypadkach po prostu usunięcie wyświetlania liczby produktów w warstwowych wynikach nawigacji zmniejszyło 2 sekundy ładowania dużej kolekcji.
• Przejrzyj powolne dzienniki MySQL. Sprawdź powolne zapytania i w razie potrzeby dodaj indeksy. Różnica między uruchomieniem złożonego zapytania z wieloma połączeniami z odpowiednimi indeksami i bez nich może wynosić kilkadziesiąt sekund .

Aplikacja jest wąskim gardłem. Nie oprogramowanie. Tak więc ulepszenie kodu podstawowego lub zmniejszenie ciężaru szablonu będzie miało znacznie bardziej dramatyczny wpływ na wydajność niż DOWOLNA zmiana konfiguracji MySQL.

Czym byśmy się nie przejmowali

• Zmiana silnika pamięci masowej. MariaDB i Percona korzystają z tego samego silnika InnoDB - Percona XtraDB. Można je traktować tak samo. Pod względem czasu wykonania pojedynczego zapytania - wydajność dokładnie odzwierciedla waniliową kompilację MySQL. To wchodzi w grę pod obciążeniem / współbieżnością.
• Uruchamianie slave MySQL. Nie poprawi to wydajności, chyba że urządzenie podrzędne znajduje się fizycznie bliżej (z perspektywy sieci) lub nie ma lepszego sprzętu niż urządzenie nadrzędne. To wchodzi w grę pod obciążeniem / współbieżnością.
• Uruchamianie zewnętrznego serwera DB. Jest to zdecydowanie najgorsza rada, którą widzimy wielokrotnie przez wielu gospodarzy / agencje. Dopóki nie osiągniesz pułapu sprzętu / zasobów lub nie będziesz mieć wielu serwerów WWW (czytaj: wysoka dostępność), MySQL na lokalnej maszynie dla sklepu Magento jest dobrym pomysłem. To odcina cały narzut sieci i opóźnienia. Nawet sieć 100 Gb / s (tak, sto gigabitów na sekundę) nie będzie się porównywać z lokalnym gniazdem unix dla surowego wolumenu, przepustowości i opóźnień.

^s1 Tylko dla oddzielnych serwerów baz danych. Nie dotyczy lokalnych serwerów DB.

Całkowita pojemność / współbieżność

Czy MySQL
może być wąskim gardłem? Ale tylko po osiągnięciu wydajności i pojemności PHP do tego stopnia, że ​​MySQL spowalnia. Jeśli masz poprawnie skonfigurowany Lakier i FPC (nie zaczynaj od liczby nieudanych prób, jakie widzieliśmy przy jednym z nich) - wtedy MySQL staje się wąskim gardłem.

Oprócz powyższych modyfikacji.

• Zmień silnik MySQL. XtraDB może przodować pod obciążeniem i wykazuje rzeczywiste korzyści w stosunku do standardowej dystrybucji MySQL.
• Bądź na bieżąco z MySQL. 5.5 działa lepiej niż 5.0 pod obciążeniem.
• Zmień sterownik PHP MySQL. PHP 5.3 i nowsze mają natywny sterownik MySQL, ale w niektórych okolicznościach znaleźliśmy PHP 5.2 z oddzielnym sterownikiem, aby przewyższyć MySQLND dla Magento. Sprawdź to sam
• Zmień wyszukiwarkę. Przeniesienie wyszukiwania do SOLR / Sphinx (lub nawet niektórych zewnętrznych usług zewnętrznych) może naprawdę zmniejszyć obciążenie związane z transakcjami (np. Osoby nie składające zamówień)
• Zmień wielowarstwowy silnik nawigacji. Ponownie, SOLR jest genialnym silnikiem do nawigacji warstwowej, a ze względu na swój nieblokujący charakter jest znacznie szybszy niż MySQL.
• Dodaj urządzenie podrzędne MySQL. To nie pomaga przeglądania (non-transakcyjnej) ładunek, ale nie pomoże Ci przetwarzać więcej zleceń na godzinę - jak to jest uzależnione od Mistrza do procesu i replikować te dane

Czym byśmy się nie przejmowali

• Master / Master. Ze względu na dość wysoki punkt krytyczny nasycenia sprzętowego konfiguracji Master / Slave (ponad 1000 zamówień na godzinę) - nigdy nie uważaliśmy za konieczne stosowanie Master / Master w produkcji. Przeprowadziliśmy szeroko zakrojone testy, ale nigdy nie stwierdziliśmy, że jest to korzystne z punktu widzenia wydajności, a przy nieodłącznym ryzyku i problemach Master / Master, po prostu nie jest tego warte.

Skalowalność odczytu i zapisu

Ostatni akapit naprawdę prowadzi do kluczowego obszaru skalowalności odczytu i zapisu. Skalowanie odczytu może być wykonywane w nieskończoność bez zbytniej komplikacji dzięki dodawaniu coraz większej liczby urządzeń podrzędnych.

Biorąc pod uwagę stosunek Magento do odczytu do zapisu wynosi około 0,1% - biorąc pod uwagę, że zapisy nie powinny stanowić większego problemu. Dlatego nie zawracałem sobie głowy wspominaniem klastra MySQL i jego sprytnych funkcji, takich jak automatyczne dzielenie fragmentów (dzielenie tabel na osobne maszyny).

Sprzęt, sprzęt, sprzęt

Sprzęt jest łatwo najszybszą odpowiedzią na ulepszenia, więc celowo nie wspomniałem o tym powyżej w obu scenariuszach.

Ale wszystkie zmiany oprogramowania na świecie nie zrobią żadnej różnicy, jeśli podstawowy sprzęt jest niewystarczający. To może oznaczać ...

• Przełączniki niskiej jakości z ograniczonymi buforami
• Zbyt nasycone łącza sieciowe
• Geograficznie odległe serwery
• Słaba jakość sieci QoS / CoS
• Ograniczona całkowita ilość pamięci RAM
• Niska przepustowość pamięci RAM
• Podsystem HDD o niskim IOP
• Oprogramowanie kontrolera RAID
• Niska prędkość zegara procesora
• Chipset o niskiej przepustowości
• Wirtualizacja sprzętowa (prawie wszystkie typy oprócz wirtualizacji na poziomie jądra)

Obecnie istnieje naprawdę wysoki pułap tego, jak wysoko można skalować sprzętowo. Zignorujmy mit nieskończonego skalowania „w chmurze”, ponieważ sprzęt w chmurze bywa dość mierny. Na przykład flagowymi modelami Amazon jest tylko 12 rdzeni @ 3,3 GHz. Ale poza tym są dostępne bardzo potężne serwery - nasz najwyższy serwer ma 160 rdzeni i 2 TB (tak, terabajty) pamięci RAM. Jeszcze nie widzieliśmy, żeby ktokolwiek przekraczał możliwości tego.

Masz więc ogromny zakres skalowania w pionie, zanim jeszcze będziesz musiał rozważyć skalowanie w poziomie.

Zawsze ruchomy cel

Warto wspomnieć, że w pogoni za wydajnością wąskie gardło zawsze będzie się poruszać.

Na magazynie sklep Magento.

Włącz skrzynki. PHP jest wąskim gardłem
Dodaj pamięć podręczną zaplecza. PHP jest wąskim gardłem
Dodaj pełną pamięć podręczną strony na poziomie aplikacji. PHP jest wąskim gardłem
Dodaj pamięć podręczną frontonu na poziomie serwera (np. Varnish). MySQL jest wąskim gardłem
Dodaj alternatywny silnik wyszukiwania / nawigacji warstwowej (np. SOLR / Sphinx). PHP jest wąskim gardłem
Dodaj więcej serwerów aplikacji. MySQL jest wąskim gardłem
Dodaj niewolnika MySQL. Wąskie gardło to wąskie gardło.
Dodaj więcej serwerów pamięci podręcznej frontonu. PHP jest wąskim gardłem
Dodaj więcej serwerów aplikacji. SOLR / Sphinx jest wąskim gardłem

Etcetera.

To prawie staje się przypadkiem powtórzenia płukania. Ale jasne jest to, że MySQL z pewnością nie jest pierwszym punktem do optymalizacji - i naprawdę wchodzi w grę tylko wtedy, gdy MySQL zużywa więcej procesora proporcjonalnie do PHP - i dzieje się tak TYLKO wtedy, gdy używany jest zarówno FPC, jak i Lakier a serwery przetwarzają wyłącznie zamówienia i nic więcej (ponieważ wszystko inne znajduje się w pamięci podręcznej).

Nie wprowadzaj zmian na ślepo

Po prostu dodanie slave MySQL, ponieważ czytasz, jak mówisz powyżej, to pomoże, może kosztować wydajność i niezawodność na ogromnym poziomie. Przeciążona sieć, serwer slave o niskiej specyfikacji, a nawet nieprawidłowe ustawienia mogą powodować problemy z replikacją, które mogą sprawić, że sklep będzie wolniejszy niż na początku - lub powodować problemy z synchronizacją między urządzeniem głównym a urządzeniem podrzędnym.

Z perspektywy czasu - przykłady z prawdziwego świata.

Przykład 1 - 300 zamówień na godzinę

Użyliśmy następującego sprzętu do obsługi 300 zamówień na godzinę ; i tylko w tym punkcie zwrotnym - wtedy poczuliśmy potrzebę dodania dedykowanego serwera MySQL i lokalnego slave MySQL.

1 serwer
CPU: 2x Intel E5-4620
RAM: 64 GB HDD: 4x 80k IOP / s SSD
RAID: sprzętowa RAID 10
Magento Wersja: Magento EE
OS: MageStack

Przez cały czas średnie obciążenia pozostawały poniżej 3,00.

Przykład 2 - 180 zamówień na godzinę

Zaledwie dwa dni temu nasz nowy klient z łatwością pochłonął duży skok ruchu. Przetwarzanie 180 zamówień na godzinę za pomocą jednego serwera i Magento Community Edition .

1 serwer
CPU: 2x Intel E5-4620
RAM: 64 GB HDD: 4x 80k IOP / s SSD
RAID: sprzętowa RAID 10
Magento Wersja: Magento CE
System operacyjny: MageStack
Strona internetowa: Wellgosh.com

Przez cały czas średnie obciążenia pozostawały poniżej 6,00. W tym scenariuszu obciążenie było wyższe i było to spowodowane kilkoma czynnikami.

1. Nie przeprowadzono strojenia po stronie sklepu, jak w przykładzie 1
2. Brak FPC na poziomie aplikacji

Biorąc pod uwagę aktualność tego faktu, nadal mamy szczegółowe statystyki, aby przekazać informacje zwrotne za pomocą wykresów. Opowiadają one doskonałą historię o rozkładzie obciążenia między kluczowe komponenty oddzielnej architektury Magento ( moduł równoważenia obciążenia, serwer WWW, serwer db itp. - za pomocą MageStack ).

Tak więc od przodu do tyłu ... data, na którą chcesz spojrzeć, to godzina 22 lutego 22 lutego.

Pakiety zapory ogniowej

Ruch lakierniczy

Ruch Nginx

Ładowanie MySQL

Obciążenie procesora

A co najważniejsze, rozkład obciążenia

Ten obraz naprawdę mówi wszystko. I to dlatego, że MySQL z pewnością nie jest obciążeniem - przynajmniej jeszcze nie. Dlatego radzimy skupić się na wydajności w innym miejscu, chyba że przetwarzamy więcej niż kilka tysięcy zamówień na godzinę.

I w podsumowaniu

Wprowadzanie zmian w wydajności nie jest „uniwersalne”. Jest to przypadek analizowania obecnych wąskich gardeł i dokonywania subtelnych zmian / dostosowań w celu dopasowania do sklepu i infrastruktury.

Pomijając wydajność, istnieją inne korzyści z używania Percona

Używamy Percona XtraDB, prawie wyłącznie. Uruchamiamy skompilowane na zamówienie kompilacje MySQL, które opracowaliśmy specjalnie dla Magento i podczas konsultacji skonsultowaliśmy się z Perconą. Ale nie tylko wydajność wpłynęła na ten wybór.

• Zestaw narzędzi Percona
  • pt-query-digest
  • xtrabackup
  • itp.
• Częstotliwość uwalniania Percona
• Wsparcie konsultacyjne Percona
• Ciepła pamięć podręczna uruchomi się ponownie z zachowaniem puli InnoDB

I wiele więcej. Używanie go w stosunku do MySQL miało jednak inne zalety niż tylko wydajność. W rzeczywistości - MySQL jest i zawsze był najmniejszym z naszych problemów w dążeniu do wydajności i stabilności.

Uznanie autorstwa: wellgosh.com , sonassi.com , iebmedia.com .