Wstępne rozgrzewanie pełnej strony pamięci podręcznej Magento Enterprise

19

Korzyści płynące z pełnej pamięci podręcznej stron w Magento Enterprise są dość dobrze znane. To, co może nie być tak dobrze znane, to fakt, że aby w pełni skorzystać z tego, musi być w pełni zaludniony i gorący, szczególnie w przypadku dużych zestawów produktów, w których nie ma tylko kilku stron, wykorzystując ruch organiczny do zalać to wystarczająco szybko.

Magento zawiera wbudowaną funkcję cronjob do indeksowania witryny i rozgrzewania FPC wcześnie rano.

Widziałem i słyszałem o problemach powodowanych przez zbyt wczesne wykonywanie zadań rano, blokujących uruchamianie innych zadań, i chciałbym wiedzieć, co inni używają lub sugerują, aby to zrobić. Mam kilka pomysłów:

  • Skompiluj skrypt powłoki, aby zindeksować każdą stronę w wygenerowanym pliku mapy witryny.
  • Użyj osobnego wpisu crontab i krótkiego skryptu PHP, aby uruchomić Magento i bezpośrednio uruchomić proces przeszukiwacza.

Wszelkie przemyślenia i / lub doświadczenia na ten temat są mile widziane!

performance cache magento-enterprise full-page-cache cron davidalger
źródło
1
W rzeczywistości możesz wywołać przeszukiwacz Enterprise z oddzielnego pliku i użyć crontab serwerów, aby go uruchomić, aby nie przeszkadzał.
Toon Van Dooren,

Odpowiedzi:

16

Możesz użyć oblężenia w połączeniu z sitemap.xmlplikiem, tak jak robi to MageSpeedTest .

#categories
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 0.5 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' > urls.txt
#products
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 1.0 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' >> urls.txt

Następnie uruchomić

siege -i -c 1 -t 7200s -f urls.txt

Treści pochodzą stąd .

Ashley Schroder
źródło
Możesz także dodać opóźnienie między żądaniami za pomocą–delay
Ben Lessani - Sonassi
Uwaga: Te polecenia sed nie działają w systemie Darwin, ale w CentOS.
davidalger
1
Nie gwarantuje to, że każdy adres URL zostanie „rozgrzany”. oblężenie losowo wybiera adresy URL do trafienia z pliku, ale niekoniecznie odwiedza każdy adres URL.
Joe Constant
22

Po prostu nie - wcale. Zawsze. Będziemy to powtarzać w kółko, ale

Buforowanie! = Wydajność

Twoja strona musi być szybka bez dodatku FPC (lub Lakier do tego faktu). Zawsze będzie czas, kiedy treść nie zostanie przygotowana (powyższy scenariusz).

W rozładowanym sklepie czasy ładowania strony z FPC nie powinny być znacznie bardziej imponujące niż z FPC; Magento z powodzeniem potrafi < 400msładować strony w standardowych pamięciach podręcznych (na stronach kategorii / produktu / wyszukiwania). FPC sprowadzi to do < 80ms- ale zawiera pewne zastrzeżenia.

  1. Informacje o zapasach / cenach są nieaktualne do momentu unieważnienia lub wygaśnięcia TTL

  2. Nowe elementy / bardziej odpowiednie wyszukiwanie jest nieaktualne do momentu unieważnienia lub wygaśnięcia TTL

    itp.

Dlaczego poleganie na FPC (lub lakierach) jest złym pomysłem

Jeśli chcesz stale zapewniać ręczne buforowanie pamięci podręcznej, prawdopodobnie istnieje kilka powodów

  1. Nie masz wystarczającej liczby naturalnych kroków, aby utrzymać pamięć podręczną w stanie zapełnionym (patrz „Gdzie przydatny jest FPC”)
  2. Bez nich Twoja strona jest zbyt wolna

Nie możesz buforować wszystkiego

Jeśli wybierzesz sklep z zaledwie 5 kategoriami, zagnieżdżony na 2 poziomach głębokości, 5 atrybutów do filtrowania, 5 opcji atrybutów i 1000 produktów; to jest wiele możliwych kombinacji.

25 opcji do wyboru, wybranie jednego do 5 razy z rzędu - nie jestem statystykem , ale wiem, że to ... (zakładając, że liczba opcji atrybutów nie zmniejszy się całkowicie)

25 possible URLs on the first selection
20 possible URLs on the second selection
15 possible URLs on the third selection
10 possible URLs on the fourth selection
5  possible URLs on the fifth selection

5^5 = 3,125 possible combinations (for top level categories)
5^4 = 625 possible combinations (for 2nd level categories)

Ok, powyższy scenariusz nie jest prawdopodobny, jak sądzę, w ciągu 3 kliknięć - liczba dostępnych produktów zmniejszyłaby się wystarczająco, aby klient mógł znaleźć swój produkt. Więc nawet gdyby to było ...

25 possible URLs on the first selection
10 possible URLs on the second selection
3 possible URLs on the third selection

5^3 = 125 possible URL combinations

Potem razy to przez 5 kategorii, czyli 625 adresów URL. Na tym etapie mówimy o małym katalogu i całkowicie ignorujemy wszystkie adresy URL produktów.

Nie bierzemy również pod uwagę faktu, że jeśli masz zagnieżdżone kategorie z is_anchor, to wykładniczo wzrośnie.

Aby więc zaindeksować tę liczbę stron - albo masz nadzieję, że czas ładowania strony będzie dobry i krótki na początek, dzięki czemu będzie to szybki i lekki proces (w ten sposób pokonując cel przeszukiwania) - lub że masz wystarczająco dużo czasu, aby ukończyć przed wygaśnięciem TTL.

Jeśli Twoje strony miały czas ładowania strony 0,4 s, a miałeś 8-rdzeniowy procesor - wtedy ...

625 * 0.4 = 250 / 8 = 31 seconds

0,5 minuty, nieźle - ale wyobraźmy sobie, że miałeś czas ładowania strony 2 s

625 * 2 = 1250 / 8 = 156 seconds

Ale jeśli wziąłeś maksymalny możliwy scenariusz

3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes

To twój serwer produkcyjny, przy 100% obciążeniu procesora przez 15 minut. Zmniejszysz prędkość pełzania proporcjonalnie do żądanego TTL.

Jeśli więc chcesz, aby treść miała 3600 sekund TTL, indeksowanie może być 4 razy wolniejsze - tj. tylko 25% procesora dedykowanego do indeksowania. To dużo zasobów, aby utrzymać kategorię treści - nie uwzględniliśmy nawet produktów, wyszukiwanych haseł ani dodatkowych wyświetleń sklepu na tym etapie

W rzeczywistości samo spojrzenie na rozmiar kombinacji w catalog_url_rewritestabeli (który nie uwzględnia nawet parametrów z nawigacji warstwowej) da wyobrażenie o tym, ile adresów URL można by przeszukać.

Każdy sklep z pewnością będzie inny, ale staram się zaatakować do domu, że indeksowanie witryny do najlepszych FPC nie jest praktyczne. Tylko upewnij się, że Twój sklep jest szybki .

Gdzie przydatny jest FPC

Korzyści płynące z gry FPC znajdują się w mocno obciążonym sklepie - gdzie masz naprawdę wysoki poziom ruchu, a skrytki są naturalnie i stale zalewane przez sam upadek.

Następnie wchodzi FPC, zmniejszając koszty infrastruktury związane z często żądanymi treściami - ograniczając liczbę powtarzających się połączeń z zapleczem Magento.

Odkryliśmy, że FPC jest świetny do wdrożenia, gdy masz bardzo duży ruch - nie w celu skrócenia czasu ładowania strony - ale w celu zmniejszenia zużycia zasobów.

Kogo to obchodzi, nadal chcę się czołgać

Masz dwie opcje

  1. Indeksowanie z szablonu (np. Mapa witryny)
  2. Wyodrębnij linki strona po stronie i zaindeksuj je

I jest wiele narzędzi do zrobienia obu z nich, niektóre z nich znam

  1. mag-perftest
  2. HTTrack
  3. Nutch
  4. Pająk
  5. Crawler4j

Korzystanie z Mag-Perftest

Możesz łatwo zindeksować swój sklep za pomocą Mage-Perftest, najpierw go pobierz

wget http://sys.sonassi.com/mage-perftest          (64bit) OR
wget http://sys.sonassi.com/mage-perftest-i386     (32bit)
chmod +x http://sys.sonassi.com/mage-perftest*

Następnie zdefiniuj proces indeksowania za pomocą mapy witryny Magento (możesz to dostosować, tworząc mapę witryny z dowolnych adresów URL, pod warunkiem, że adresy URL są zawinięte w <loc></loc>tagi). Następujące polecenie odczyta wszystkie adresy URL z pliku mapy witryny, a następnie zaindeksuje (tylko PHP) adresy URL w ciągu 1440 minut (1 dzień). Jeśli serwer przekroczy 20% CPU lub średnie obciążenie 2, przeszukiwanie zostanie chwilowo wstrzymane.

./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2

Jeśli masz 1000 adresów URL, zaindeksowanych w ciągu 1 dnia, będzie to ok. 1 żądanie co 86 sekund (y) ~ docelowa wartość 0,011 RPS

Ben Lessani - Sonassi
źródło
Twoja linia początkowa jest bardzo prawdziwa… buforowanie stron nie jest sposobem na osiągnięcie wydajności. Wiem to. Nie wiesz, ile razy mówiłem klientom to samo. Będę szczery, nigdy wcześniej nie konfigurowałem strony, w której mamy robota sterującego FPC, i widziałem, że był używany tylko raz, gdy klient włączył go w adminie… spowalnia rzeczy, ponieważ tagi plików oparte na pamięci podręcznej. Głównym powodem, dla którego pytam, jest to, że badam pomysły związane z tym na podstawie badań w białej księdze Nexcess. W przypadku witryn o wyjątkowo dużym natężeniu ruchu, przygotowanie pamięci podręcznej po opróżnieniu jej wcześnie rano może być krytyczne
davidalger
1
Szanuję Nexcess - ale ich biała księga bardzo mocno koncentruje się na buforowaniu w celu osiągnięcia wydajności - zamiast na zapewnieniu, że środowisko jest już wydajne i że kod jest czysty, szybki i wydajny. Zapewniamy lakier dla naszych klientów - ale nie zalecamy jego stosowania, dopóki nie będzie to wymagane. Tylko wtedy jako sposób na obniżenie kosztów infrastruktury - tj. gdy ~ 94% ruchu nieodwracającego / kasującego zużywa cykle procesora. Buforowanie tworzy dobre sztuczne statystyki porównawcze - ale w rzeczywistości nic nie znaczy, jeśli TTL są zbyt długie (przestarzała zawartość) - lub nie ma wystarczającego ruchu, aby utrzymać go w stanie pierwotnym.
Ben Lessani - Sonassi
1
W przypadku witryn o wyjątkowo dużym ruchu - mamy kilka, a próba utrzymywania pamięci podręcznej przez sztuczne indeksowanie jest bezcelowa - naturalny ruch robi to dobrze. Jeśli już, to indeksowanie usuwa zasoby, które w innym przypadku byłyby wykorzystywane przez klientów.
Ben Lessani - Sonassi
Zaczynam różnicować się w białej księdze, która koncentruje się na używaniu buforowania do wydajności. Pokazali, ile przepustowości może osiągnąć klaster 2 + 1. Nie dotknęli nawet czasu ładowania strony, a jedynie przepływność transakcji. Sprzęt, który mają, jest prawie tak zoptymalizowany, jak to tylko możliwe… i tak, zdaję sobie sprawę z wpływu TTL na buforowaną zawartość. Żeby powtórzyć, nie chcę tutaj osiągać wydajności, już to mamy. To byłoby zbadanie sposobów obejścia opóźnień / spadków przepustowości spowodowanych wczesnym porannym opróżnianiem pamięci podręcznej, tj. Przed rozpoczęciem normalnego ruchu.
davidalger
1
Jestem zdezorientowany. Jeśli Twój sklep jest już szybki - ale przewraca się po wyczyszczeniu pamięci podręcznej. Albo a) Nie czyść pamięci podręcznej rano, zrób to poprzedniej nocy i pozwól wyszukiwarkom zaindeksować boty (google / bing itp.), Przygotowując dla ciebie, lub b) uzyskaj odpowiednią infrastrukturę. Jeśli twój sklep opiera się na FPC / Varnish, aby zapobiec opóźnieniom / spowolnieniu - brzmi to tak, jakbyś biegał jak nóż ...
Ben Lessani - Sonassi
0

W tych dniach zachowam całą swoją ofertę na blogu, ale w międzyczasie mam szczyt w moim małym cieplejszym buforze wfpc.

Testowanie wydajności

Możesz przetestować wydajność swojej strony Magento

./wfpc -t http://mymagentosite.com/sitemap.xml

Finished testing your Magento site performance
Total download time (in seconds)   : 5.0269110202789
Total download time (formatted)    : 0:0:5.026
Average page time (in milliseconds): 502.69110202789

Ocieplenie FPC

Możesz ogrzać FPC, który trafi na każdy adres URL w sitemap.xml.

./wfpc -w http://mymagentosite.com/sitemap.xml

Jeśli chcesz, możesz także opóźnić między żądaniami, oto 1 sekundowe opóźnienie między żądaniami.

./wfpc -w -d=1 http://mymagentosite.com/sitemap.xml

Tryb testowy trafia tylko 10 adresów URL losowo, więc po rozgrzaniu FPC możesz uruchomić tryb testowy, aby dowiedzieć się, jaką różnicę robi FPC!

Myśli

Osobiście uważam, że cieplej ma sens ... Na małej stronie z około 40 stronami czas pobierania skraca się o około połowę przez FPC. Na dużej stronie z prawie 40 000 produktów używających Lesti_FPC z APCu jako backendem, używam nieco ponad 200 MB pamięci podręcznej, co szczerze mówiąc, nie jest niczym na serwerze produkcyjnym o pojemności 8 GB.

szybka zmiana
źródło