Obecnie pracujemy z wymogiem, że pierwsza odpowiedź z serwera WWW musi przyjść w Wielkiej Brytanii poniżej 200 ms. Obecnie pod 2 dedykowanymi serwerami WWW z modułem równoważenia obciążenia i 1 serwerem db, wchodzimy na 800ms.

W tej chwili strona ma mniej niż 5 klientów, 2 produkty, 4 kategorie, w tej chwili nie ma frontu witryny, jest stylowa i bez obrazów.

Jest także uruchamiany na nginx z Varnish.

Czy ktoś może mi udzielić porady na temat konfiguracji serwera WWW? Dlaczego nasz przybywa powoli? Co możesz polecić, aby to zoptymalizować? Musisz uzyskać 400% szybciej!

Ugryzę.

Ta pierwsza odpowiedź z serwera internetowego musi przyjść w Wielkiej Brytanii poniżej 200 ms.
W tej chwili nie ma interfejsu użytkownika, jest on stylowy i wolny od obrazów.

Nie osiągniesz tych liczb bez pomocy Lakieru lub FPC (lub obu). Z pewnością miałbym nadzieję, że postać nie musi także zawierać treści statycznych (ilekroć zdecydujesz się ją dodać) - ponieważ jest to prawie niemożliwe do osiągnięcia (poza tym, że nie ma prawie żadnych obrazów / js / css).

Wchodzimy o 800ms.
Jest również uruchamiany na Nginx z Varnish

Źle skonfigurowano Lakier.

Prawidłowo skonfigurowana instalacja Varnish zapewni czasy ładowania strony <100 ms (bliżej <10 ms).

W rzeczywistości dla Magento powinieneś spodziewać się czegoś takiego,

Gdy klient nie jest zalogowany ...
Tj. Brak utworzenia unikalnej sesji (dodawanie do koszyka / listy życzeń, logowanie itp.)

--1.2s--------0.8s-----------------0.6s----------------0.1s--------------0.08s----
  Uncached    Mage default cache   Partial FPC cache   Total FPC cache   Varnish

Gdy klient jest zalogowany ...
Tj. Po utworzeniu unikalnej sesji (zalogowany, przedmioty w koszyku itp.). W tym momencie Lakier prawdopodobnie będzie wyłączony. A jeśli zdecydujesz się na użycie ESI - w zależności od wywołań odwrotnych, może on utrzymywać podobny czas ładowania strony jak pamięć podręczna FPC (z powodu narzutu ładowania początkowego) - lub faktycznie wydłużyć czas ładowania strony poza buforowaniem.

--1.4s--------0.8s-----------------0.6s--------------
  Uncached    Mage default cache   Total FPC cache   

To nie jest przypadek strojenia Lakieru - to przypadek - „w rzeczywistości niczego nie buforujesz” .

Idealne pliki konfiguracyjne serwera Magento

Nie ma jednego, cóż, niezupełnie.

Obsługujemy ponad 400 serwerów, wszystkie sklepy wyłącznie Magento - o różnych rozmiarach i pojemności. I rzadko zdarza się, że pliki konfiguracyjne, które mamy na jednym - pasują do innego. Jest tak, ponieważ nie wszystkie firmy są do siebie podobne.

Wąskie gardła mogą powstawać z wielu różnych powodów:

1. Duża liczba współbieżności użytkowników z aktywnymi sesjami
2. Ofiary „złych” botów pełzających, generujących niezbędne, nieocenione obciążenie
3. Wysoki odsetek warstwowych trafień nawigacyjnych
4. Duża liczba zapytań wyszukiwania
5. Duża ilość transakcji na godzinę
6. Źle zbudowany szablon
7. Zbyt wiele / powolnych / nieporęcznych rozszerzeń innych firm
8. Nieaktualne linki przychodzące prowadzące do wysokiego odsetka 404 trafień
9. Limit pojemności interfejsu sieciowego
10. Duży / złożony katalog (wiele produktów / kategorii / atrybutów)

Tak więc w przypadku sklepów w całym tym spektrum każdy z nich ma inne podejście do bardziej optymalnej wydajności.

Aby rozwiązać problemy opisane powyżej; celowo unikniemy po prostu stwierdzenia „więcej / lepszy sprzęt”

1. Użyj FPC wykraczającego poza Lakier
2. Odfiltruj / zablokuj złe boty na brzegu sieci - lub przekieruj wszystkie żądania do Varnish bez względu na stan / adres URL pliku cookie
3. Zmień nawigację warstwową na SOLR, uzależnij filtry nawigacji warstwowej
4. Zmień wyszukiwanie towaru na SOLR
5. Rozłóż obciążenie MySQL w konfiguracji Master / Slave - rób to tylko wtedy, gdy masz zagwarantowane, że obciążenie przeglądania zostanie przejęte przez Varnish / FPC
6. Ponownie skompiluj szablon
7. Rozbierz je
8. Ciągłe monitorowanie dzienników dostępu i przepisywanie adresów URL w Nginx / Varnish przed dostawą. Jeśli robisz to na poziomie Nginx - upewnij się, że Lakier buforuje przekierowania 301/302.
9. Podziel zawartość statyczną na CDN lub popraw łączność
10. Dodaj więcej sprzętu (w pewnym momencie musieliśmy to powiedzieć)

Mając to na uwadze - zobaczysz, że prawdopodobnie nie będzie pliku konfiguracyjnego Nginx, pliku konfiguracyjnego puli PHP fcgi, pliku konfiguracyjnego MySQL lub pliku konfiguracyjnego Varnish, które będą takie same. Połącz to ze zmianami sprzętu; dostępna pamięć, wydajność I / O (HDD i sieć) oraz procesor - zauważysz, że istnieją subtelne wariacje, które prowadzą do pożądanego wzrostu wydajności o 400% - ale nie ma jednej szybkiej odpowiedzi, którą łatwo znajdziesz w Internecie.

Możesz skopiować i wkleić sponsorowaną przez Peer 1 białą księgę Magento na temat wydajności (nie zalecamy jej); mam nadzieję, że ustawienia nie przekroczą dostępnej pamięci, limitów wątków, stanów TCP / IP, pojemności I / O i doprowadzą do mniejszej wydajności niż waniliowa konfiguracja Apache / mod_php.

Więc kontynuujmy.

Idealny stos serwerów Magento

Jest to bardziej prawdopodobne, że zbliżysz się do rzeczywistości. Dobrym przykładem na zademonstrowanie tego jest pokazanie, jak skonfigurowany jest dedykowany system Magento, MageStack

Weź oddzielne podskładniki, a otrzymasz listę najbardziej optymalnego / krytycznego oprogramowania, jeśli zostanie odpowiednio skonfigurowane , do prowadzenia sklepu Magento. Szczególnie:

Zapora ogniowa, filtr DOS, moduł równoważenia obciążenia, lakier, Nginx, PHP, Redis, Memcached, MySQL

Więc kiedy zapytasz:

Jaka jest najlepsza konfiguracja serwera Magento?

Jaki jest dokładnie twój cel?

1. Duża dostępność
2. Niezawodność
3. Prostota administracji
4. Występ
5. Skalowalność

Dość wykładów, jak byśmy to zrobili

Aby częściowo odzwierciedlić odpowiedź podaną w przypadku błędu serwera w podobny sposób. Masz do dyspozycji 3 serwery - więc najpierw zorientuj je tak optymalnie, jak to możliwe. Unikniemy wysoce dostępnego rozwiązania, ponieważ wykracza to daleko poza zakres tej odpowiedzi.

Podskładniki wymagane do konfiguracji z wieloma serwerami to:

• Zapora ogniowa
• Moduł równoważenia obciążenia
• Serwer internetowy
• Serwer MySQL
• Wspólne przechowywanie

Więc będziemy wielofunkcyjność niektórych systemów. Zgodność z PCI-DSS określa rolę każdego serwera. Zatem z 5 rolami i 3 serwerami - natychmiast naruszysz. MageStack rozwiązuje ten problem za pomocą wirtualizacji - możesz zrobić to samo.

Serwer 1: Load Balancer + serwer WWW
Serwer 2: serwer WWW
Serwer 3: serwer bazy danych

Bez opóźnień i znacznej przepustowości sieci (> 1 Gb / s, <125µs), zamiast wspólnego magazynu - lepiej jest przechowywać katalog główny sklepu na każdym komputerze i replikować dane w czasie rzeczywistym ionotifylub za pomocą cronpraca. Ponownie unikniemy sieciowych systemów plików, takich jak NFS, lub replikowanych urządzeń blokowych, takich jak Gluster lub DRBD - ponieważ wymagane jest szerokie dostrojenie i przyzwoita przepustowość sieci.

Lakier musi siedzieć jak najbliżej przodu. Ale Varnish nie może odszyfrować SSL. Więc połącz to z terminatorem SSL; Nginx, Funt, Stunnel, Stud itp. Wbudowany moduł równoważenia obciążenia w Varnish nie jest świetny - ale byłby odpowiedni dla konfiguracji 2 serwerów.

Nginx + PHP-FPM jest w porządku, ale nie pij za dużo pomocy kool Nginx. Będzie działał prawie identycznie jak tradycyjna konfiguracja Apache / mod_php, oto kilka dobrych lektur na temat tego, dlaczego nie używać Nginx . Nginx jest dobry, bardzo dobry, ale z pewnością nie jest wąskim gardłem sklepu Magento - i biorąc pod uwagę jego złożoność i brak natywnej obsługi Magento. Większość początkujących administratorów systemu skorzystałoby na korzystaniu z Apache / mod_php nad czymkolwiek innym. Może to wydawać się archaiczną rekomendacją w stosunku do korzystania z PHP-FPM - ale nasze testy wydajności wykazały, że wydajność jest tylko ~ 7% szybsza w przypadku rozwiązania Nginx - przy odpowiedniej konfiguracji. Strojenie i doświadczenie wymagane do uzyskania wysokiej wydajności, niezawodnej konfiguracji Nginx / PHP-FPM jest dość duże, aby uzyskać lepsze wyniki niż Apache / mod_php. Niezależnie od tego, co wybierzesz, jest to połączenie.

Serwer bazy danych jest prosty, MySQL. Ale jak wspomniano wcześniej, jeśli masz witrynę o wysokiej konwersji, zaleca się konfigurację Master / Slave. To, czy należy zastosować to podejście, można ustalić, czytając ten artykuł .

Następnie twoje zewnętrzne pamięci podręczne, Memcached i Redis. W mniejszych sklepach przechowywanie sesji w jednej instancji Memcache, a szybkiej pamięci podręcznej backend w innej, zapewni dobre wyniki. Nie zalecamy przechowywania tagów pamięci podręcznej w wolnym backendie - powoduje to więcej problemów niż daje. Tak więc w przypadku konfiguracji Memcached będziesz musiał utracić oznaczanie pamięci podręcznej . Zamiast tego używamy konfiguracji jak ten .

Redis nie pochodzi z Magento, ale z rozszerzeniem Colin Mollenhour - jest to lepsze rozwiązanie niż Memcache, obsługuje tagi pamięci podręcznej, pamięć sesji, a nawet trwałe pamięć podręczną - nie jest tak niestabilna jak Memcache . Ale ma to swoje wady. W dużych sklepach produkcyjnych (> 500 zamówień na godzinę,> 30 000 unikalnych na godzinę) odkryliśmy, że pamięć podręczna (i tagi) mogą się bardzo szybko zapełnić, a po osiągnięciu punktu nasycenia mechanizm LRU nieco zawodzi ( pomimo różnych ustawień) i powoduje ogromne natychmiastowe wąskie gardło. Dlatego rozsądne jest ręczne przycinanie starych rekordów.

Więc do jakiego sprzętu należy użyć?

Serwery sieciowe: najszybszy procesor, większość rdzeni procesora, stosunek 2 GB pamięci RAM / rdzeń
Serwer DB: szybki procesor, najszybsze we / wy dysku, większość pamięci RAM

Dlatego przy wielokrotnym celowaniu 3 maszyn najlepszym układem byłoby:

Serwer 1: Terminator SSL -> Lakier -> Nginx / Apache> PHP
Serwer 2: Nginx / Apache> PHP, Redis, (MySQL Slave)
Serwer 3: MySQL

Co do konkretnej konfiguracji każdej aplikacji. Wszystko zależy od specyfikacji sprzętu, złożoności sklepu, typu i charakteru odwiedzających oraz liczby odwiedzających.

Jesteś na dobrej drodze z tą konfiguracją klastra. Polecam dodanie dedykowanego hosta pamięci podręcznej dla Redis; wybierz jeden z wysoką mocą procesora i dużą ilością pamięci RAM (~ 64 GB).

Oto pełna lista konfiguracji, których użyłem dla wysoce dostępnego, odpornego na awarie, rozproszonego i zbalansowanego klastra LEMP. Obejmuje ona app/etc/local.xml, w core_config_datatabeli i konfiguracje dla MySQL, PHP-FPM, nginx i Redis. Wszystkie działają w systemie Ubuntu 12.04 LTS 64-bit. Konfiguracje zawierają wiele optymalizacji bez wad.

Najważniejsze

• Administratorzy: 46
• Kategorie: 2450 (największy z 2400 produktów)
• Podmioty produktu: 101 000
• Produkty kombinowane: 484
• Relacje produktowe: 54,000
• W magazynie i dostępne konfigurowalne produkty: 10 100
• Bloki CMS: 3100
• Strony CMS: 1400

Ruch w sierpniu 2013 r .:

• 40 milionów odsłon miesięcznie
• 2,3 miliona unikalnych odwiedzających
• 46 000 kas miesięcznych
• 89% odwiedzających z USA

Hosty internetowe

Za redundantnymi, wysoce dostępnymi zaporami sprzętowymi i równoważącymi obciążenie sprzętem znajduje się 10 hostów. Większość zasobów statycznych jest odciążonych do CDN.

• średni czas reakcji w całej witrynie: 282 ms
• Średnia odpowiedź FPC: 48 ms
• średnia obciążenia: 0,6 do 1,0 (w testach wydajność spada o 35%, gdy średnie obciążenia osiągają ~ 5,0)
• Podwójny procesor Intel Xeon E3-1230 V2 @ 3,30 GHz (4 rdzenie każdy)
• 32 GB pamięci RAM DDR3 1333 MHz

Moduły

• https://github.com/colinmollenhour/Cm_RedisSession
• https://github.com/colinmollenhour/Cm_Cache_Backend_Redis
• https://github.com/aligent/CacheObserver.git --branch = modele
• https://github.com/aligent/Lokey_ShippingAdjustments
• https://github.com/aligent/VF_CustomMenu.git --branch = produkcja
• https://github.com/Vinai/customer-activation
• https://github.com/gknoppe-guidance/magento-cachebuster

Hosty pamięci podręcznej

Istnieją dwa hosty z systemem Redis w konfiguracji master-slave z automatycznym przełączaniem awaryjnym. Trzy instancje Redis (sesje, backend i FPC) są używane do zwiększenia przepustowości i zapewnienia dostrajania zachowań trwałości.

• 3000 poleceń na sekundę
• Średni czas odpowiedzi 0,7 ms
• obciążenie średnio od 1,0 do 1,5
• Czterordzeniowy procesor Intel Xeon E5-2620 0 @ 2,00 GHz (po 6 rdzeni)
• 128 GB buforowanej pamięci RAM DDR3 1333 MHz
• Dyski mechaniczne, RAID 1, kontroler sprzętowy

Hosty baz danych

Istnieją dwa hosty z systemem MySQL 5.6.11 w konfiguracji master-slave z ciepłym przełączaniem awaryjnym.

• 1500 poleceń na sekundę
• Średni czas odpowiedzi 1,1 ms
• średnia obciążenia 0,1 (master) i 0,4 (slave)
• Czterordzeniowy procesor Intel Xeon E7- 2860 @ 2,27 GHz (10 rdzeni)
• 128 GB buforowanej pamięci RAM DDR3 1333 MHz
• SSD, RAID 1 + 0, kontroler sprzętowy
• MySQL 5.6.11 z tcmalloc

Innym musi być wskazówka serwera dla Magento instalującego PHP 5.4 lub 5.5 z OPcache . PHP 5.4 jest znacznie szybszy niż 5.3 ( http://www.eschrade.com/page/magento-performance-on-php-5-3-5-4-and-5-5rc3/ ).

Chcę dodać kolejną ważną wskazówkę, która poprawiła szybkość strony Magento, gdy nie jest buforowana przez lakier i nie jest domyślnie włączona (czas ładowania strony koszyka zmieniono z 6sc na 1,5sc).

Aktywuj pamięć podręczną zapytań mysql w /etc/mysql/my.conf

query_cache_size = 268435456
query_cache_type= 1
query_cache_limit=1048576

włącz typ bufora, rozmiar bufora to wartość używana przez bufor w pamięci, a limit bufora to maksymalny rozmiar wyniku zapytania do bufora

Przy obecnej konfiguracji otrzymujemy wstępną odpowiedź w 400 ms, a dokument ukończony w 2 sekundy (przy standardowym połączeniu 5 Mb / s). Nasz rozmiar strony głównej to 1 MB.

Nasza konfiguracja oparta jest na AWS w następujący sposób: Mamy instancję ec2 z modułem równoważenia obciążenia podłączonym do bazy danych RDS (z przełączaniem awaryjnym). Wdrożyliśmy również pełną pamięć podręczną strony z zapleczem pamięci podręcznej redis dla pamięci podręcznej i pamięci sesji.

Średnio mamy 300 - 400 odwiedzających dziennie, ale z włączonym buforowaniem redis mieliśmy minimalne zużycie zasobów ec2 przy jednoczesnym zachowaniu szybkości i obniżeniu kosztów.

Powodem, dla którego mamy moduł równoważenia obciążenia, jest to, że ec2 jest skonfigurowany tak, aby automatycznie uruchamiał nową instancję, jeśli w rzadkich przypadkach mamy gwałtowne skoki ruchu, których bieżąca konfiguracja nie jest w stanie obsłużyć.