Magento Automatic Caching Insight

Używamy Magento EE 1.11 z Memcache. 2 GB na serwer memcahce, łącznie 4 GB. Mamy około 240 tys. Produktów.

• Dostępne pamięci RAM: 6 GB
• Rdzenie: 16
• Wątki: 32

Oto oferta, więcej nowych produktów jest dodawanych, a zmiany w produktach pojawiają się codziennie i oczywiście za każdym razem, gdy nowy produkt jest dodawany / modyfikowany na zapleczu, pamięć podręczna zostaje unieważniona, w szczególności pamięć podręczna pełnej strony.

Gdy Magentos Auto Cache Generation jest włączone, zbudowanie pamięci podręcznej zajmuje około 2 dni, a robotowi przydzielono 8 wątków. Po 2 dniach memcache unosi się wokół ~ 2 GB oddzielonych między dwoma dyskami RAM.

Problem polega na tym, że gdy produkty są modyfikowane codziennie, pamięć podręczna zostaje unieważniona, a gdy tylko „Pełna pamięć podręczna strony” zostanie odświeżona, te 2 GB pamięci podręcznej wracają do pierwszego, 0, a cykl lepkiej pamięci podręcznej Magentos Auto zaczyna się od nowa. Teraz pamięć podręczna nie tylko wraca do 0, ale zużycie procesora wzrasta do 90%, a strona zmienia się w grę czekającą ponad 5-10 sekund i możesz po prostu zapomnieć o próbie zamówienia produktu o ponad 100 odmianach, jeśli jest bez pamięci podręcznej załadowanie za pierwszym razem zajęłoby kilka minut, to niedorzeczne.

Więc moje pytania do społeczności.

• Czy istnieje sposób, aby Magento automatycznie „aktualizował” pamięć podręczną, jeśli zostanie unieważniony, bez odbudowywania całej pamięci podręcznej i rozpoczynania od 0? Wiem, kiedy pamięć podręczna jest unieważniona, że ​​Magento wie, że coś się zmieniło, ale nie dokładnie gdzie w pamięci podręcznej (popraw mnie, jeśli się mylę). Czy są dostępne moduły / konfiguracje do ominięcia przebudowywania całej pamięci podręcznej?

Na marginesie używamy modułu LightSpeed ​​Tiny Bricks.

• Czy Magentos Automatic Cache Generation może być kontrolowany czasowo za pomocą cronjob? Powiedzmy, aby rozpocząć indeksowanie od 22:00 do 6:00.

• Jaki byłby najlepszy sposób podejścia do tej sytuacji ?, ponieważ rozumiesz, że odbudowywanie pamięci podręcznej, która jest w gigabajtach każdego dnia, jest po prostu niedopuszczalne.

Nie masz prawie wystarczającej ilości pamięci RAM

Mamy około 240 000 produktów
Dostępne pamięci RAM: 6 GB
Wątki: 32

Nie masz prawie wystarczającej ilości pamięci RAM dla ilości posiadanych produktów. Zasadniczo zalecamy co najmniej 2-4 GB pamięci RAM na rdzeń logiczny.

Jeśli zmapujesz możliwe użycie pamięci:

• 64 wątków PHP o max_memorywielkości ~ 768 MB = 24 GB
• 240 000 produktów będzie prawdopodobnie oznaczać około 15 GB przestrzeni tabel InnoDB
• 64 wątków PHP gwarantuje około 128 połączeń MySQL, zazwyczaj kosztuje to około 200 MB na połączenie minimum
• Pamięć masowa zaplecza dla 240 000 produktów w lzfskompresowanym systemie Redis ORAZ nadal zużywa około 6 GB pamięci RAM

Łącznie do tej pory wynosi 70 GB pamięci RAM - nie wspomnieliśmy nawet o systemie operacyjnym itp.

Twój sprzęt jest strasznie nieokreślony . Sugerowałbym przeczytanie tego artykułu na temat konfiguracji serwera Magento, aby trochę rozejrzeć się za postępem.

Memcached nie obsługuje tagów pamięci podręcznej

Jeśli używasz Memcached (to nie jest problem, jego bardzo wysoka wydajność), to albo przechowujesz tagi pamięci podręcznej, albo nie. Jeśli nie masz slow_backendzdefiniowanej - to nie przechowujesz tagów, co w zasadzie oznacza, że ​​twoja pamięć podręczna nie może rozróżniać żadnego z różnych typów pamięci podręcznej - więc nie będziesz w stanie opróżnić ich niezależnie.

Przeczytaj to, http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/

Zdecydowanie zalecamy przejście na Redis. Ma swoje dziwactwa i wymaga znacznego dopracowania w przypadku większych sklepów. Ale jako całość będzie działać nieco lepiej niż Memcached z prawdziwą zaletą obsługi tagów pamięci podręcznej.

404 i FPC

FPC ma prawdziwy problem, w rzeczywistości wszystkie silniki buforujące mają problem z 404. Powodem jest to, że wszystkie stare adresy URL, które wciąż są indeksowane lub do których prowadzą linki, trafią na stronę, która musi iterować całą core_url_rewritetabelę, spróbować znaleźć dopasowanie do wszystkich zdefiniowanych routerów i przestrzeni nazw, zanim ostatecznie zrezygnuje z ładowania 404.

Następnie buforuj zasób, który nie ma wartości i zużyje miejsce w pamięci podręcznej. Prawdopodobnie okaże się, że ogromna część pamięci Memcached jest zjadana przez 404 treści.

Dzięki dużym katalogom (240 tys. Produktów) na pewno będziesz mieć uczciwy udział w obrotach produktami, a tym samym zmianach adresów URL, a następnie wielu 404.

FPC Invalidate vs. Clean

W tej chwili - i domyślnie - zachowanie FPC polega na czyszczeniu pamięci podręcznej po zmianach, a nie tylko unieważnianiu wpisu pamięci podręcznej. Napisaliśmy rozszerzenie, aby zmienić to zachowanie, aby sklep EE robił dokładnie to, czego potrzebujesz.

Oto krótka łatka, która daje wyobrażenie o tym, jak rozwiązać problem.

app/code/core/Enterprise/PageCache/etc/config.xml
index 6a56a80..85ebc92 100644
--- app/code/core/Enterprise/PageCache/etc/config.xml
+++ app/code/core/Enterprise/PageCache/etc/config.xml
@@ -139,7 +139,7 @@
             <observers>
                 <enterprise_pagecache>
                     <class>enterprise_pagecache/observer</class>
-                    <method>cleanCache</method>
+                    <method>invalidateCache</method>
                 </enterprise_pagecache>
             </observers>
         </catalogrule_after_apply>

Nie uruchamiaj robota

Jeśli masz dość przyzwoitych kroków - nie zalecamy uruchamiania narzędzia indeksowania, ponieważ generuje ono niepotrzebne obciążenie. Osoby / boty / roboty indeksujące przeglądające witrynę powinny mieć pamięć podręczną przygotowaną.

Ale aby odpowiedzieć na twoje pytanie, jeśli spojrzysz na wspomniany wyżej plik konfiguracyjny - zobaczysz harmonogram cron, który został zdefiniowany dla okna przeglądania indeksowania.

Jeśli możesz sobie pozwolić na przestarzałe treści

I ostatecznie, jeśli masz wystarczającą ilość pamięci RAM. Możesz również skorzystać z zwiększenia TTL treści przechowywanych w FPC - aby zachować przechowywane dane w pamięci podręcznej na dłużej.

W <full_page_cache>tagu po ./app/etc/local.xmlprostu zdefiniuj

<lifetimelimit>86400</lifetimelimit>

Czas życia określa się w sekundach. Musisz znaleźć równowagę między świeżością treści, wydajnością a ilością faktycznie dostępnej przestrzeni dyskowej.

Dlaczego korzystasz z zewnętrznego rozszerzenia buforowania z EE

Płacisz premię za FPC - co mnie boli, że jest bardzo dobra. Dlaczego więc używasz alternatywnych rozwiązań innych firm od początku. Usunąć to.

To w ten sposób. Jeśli twój samochód działał źle - czy po prostu dodasz inny silnik do bagażnika, aby to zrekompensować; lub po prostu naprawić silnik już tam?

Rozumiemy Cię bardzo dobrze! Codziennie dodajemy nowe lub zmieniamy nasze produkty, a także modyfikujemy bloki statyczne. Byliśmy więc skończeni z unieważnioną pamięcią podręczną Magento i tą stałą przechodzącą do System -> Zarządzanie pamięcią podręczną. Nienawidziliśmy konieczności ręcznego odświeżania unieważnionych typów pamięci podręcznej.

Następnie zainstalowaliśmy nowe rozszerzenie Magento Optimizer . Ten moduł automatyzuje ten proces. Odświeża unieważnione / wszystkie typy pamięci podręcznej lub opróżnia pamięć podręczną Magento z określoną częstotliwością. To była prawdziwa ulga dla całego naszego zespołu!

Kolejną wielką zaletą tego rozszerzenia jest to, że czyści pliki sesji i raporty błędów, które są starsze niż X dni. Wszyscy wiedzą, że rozmiar katalogów var / session i var / report może wzrosnąć do gigabajtów, a liczba tych plików może przekroczyć sto. Dlatego teraz, aby spowolnić działanie strony, ustawiliśmy Magento Optimizer raz i zapomnieliśmy o okresowym odświeżaniu tych katalogów.

Magento jest znane z łączenia porzuconego koszyka z bieżącym, gdy klienci próbują się zalogować. Z doświadczenia i lojalności klientów jest to destrukcyjne. Moduł Magento Optimizer automatycznie usuwa porzucone wózki starsze niż X dni. Możesz użyć tej funkcji również w czasie wyprzedaży i ograniczyć czas dla porzuconych koszyków.