Magento Cache - zamieszanie na temat lakierów, Redis, APC, Memcache

Próbuję poprawić wydajność Magento (wkrótce czy później „MageDev” osiągnął ten punkt :)

Przeprowadziłem badania i znalazłem wiele dobrych, ale nie jednorodnych przewodników.

Mam to:

• MemCache lub Redis to ogólny system pamięci podręcznej, buforują dane i mogą być zintegrowane bezpośrednio z Magento ( local.xml )
• APC to pamięć podręczna dla samego kodu php, którą można zintegrować tylko na poziomie serwera.
• Lakier jest odwrotnym proxy, buforuje odpowiedź można zintegrować tylko na poziomie serwera. (istnieje rozszerzenie dla Magento, terpentyna, ale nie jestem pewien, co dokładnie robi)

Po tych wszystkich dobrych lekturach nadal jestem trochę zdezorientowany, co z powyższych systemów pamięci podręcznej można używać w kombinacjach, na przykład dla EX:

• MemCache + APC?
• Redis + APC?
• czy mogę dodać lakier do jednej z powyższych konfiguracji?

Żeby było jasne, pytanie nie dotyczy tego, jak skonfigurować Magento lub serwer, ale jakie są dozwolone możliwości i pewne wyjaśnienia na temat mieszania systemów pamięci podręcznej. (poza tym, jeśli ktokolwiek może przyjść z dobrą rekomendacją, byłbym wdzięczny dzięki.)

TL; DR - W MageStack używamy Varnish, Redis (pamięć podręczna), Redis (sesje) i Eaccelerator / Zend OPCache (w zależności od wersji PHP)

Już to zrozumiałeś.

Backend pamięci podręcznej, magazyn sesji, pamięć podręczna opcode, pamięć podręczna pełnej strony i pamięć podręczna odwrotnego proxy są całkowicie różne.

Możesz używać różnych technologii dla wszystkich i możesz używać WSZYSTKICH jednocześnie (w tym Lakier i FPC)

Backend pamięci podręcznej

• Pliki (rdzeń) Domyślnie
• Memcache (rdzeń)
• APC (rdzeń)
• Redis (<1,9 moduł dzięki uprzejmości Colin Mollenhour)
• MongoDB (moduł dzięki uprzejmości Colin Mollenhour)
• Rubic (moduł dzięki uprzejmości Daniel Sloof)

Możesz użyć tylko jednego zaplecza pamięci podręcznej.

Wbrew powszechnemu przekonaniu użycie pamięci podręcznej opartej na pamięci nie poprawi wydajności. Ale przezwycięży on pewne fatalne wady w domyślnym buforowaniu opartym na plikach Magento.

W chwili pisania tej wiadomości Redis jest moją rekomendacją.

Sklepy z sesjami

• Pliki (rdzeń) Domyślnie
• Memcache (rdzeń)
• Redis (<1,9 moduł dzięki uprzejmości Colin Mollenhour)
• MongoDB (moduł dzięki uprzejmości Colin Mollenhour)

Możesz użyć tylko jednego sklepu sesyjnego.

Wbrew powszechnemu przekonaniu korzystanie z magazynu sesji opartego na pamięci nie poprawi wydajności.

W chwili pisania tej wiadomości Redis jest moją rekomendacją.

OpCode Cache

• APC
• XCache
• Eaccelerator (PHP <5.4)
• Zend OPCache (PHP> 5.4)

Możesz faktycznie zainstalować wiele pamięci podręcznych kodów operacyjnych, ale nie jest to zalecane, ani nie spodziewałbym się żadnych korzyści.

Moje rekomendacje znajdują się w nawiasach powyżej.

Aby to wykorzystać, nie trzeba instalować żadnego modułu.

Odwróć pamięć podręczną proxy

• Lakier
• Nginx
• Apacz
• … i wiele więcej

Możesz używać wielu odwrotnych serwerów proxy, a chociaż jest to złożone i podatne na wydłużanie pamięci podręcznej, może mieć zalety (tj. Zapobiegać stemplowaniu podczas opróżniania pamięci podręcznej).

Użyj jednego, jeśli to konieczne (tj. Nie w celu przyspieszenia wolnej witryny, ale w celu zmniejszenia zużycia zasobów w szybkiej witrynie).

Aby wykorzystać odwrotny serwer proxy, wymaga zarówno włączenia serwera, jak i modułu Magento.

Powodem tego modułu jest pomoc w kontrolowaniu logiki buforowania (tj. Informowanie bufora, co powinno, a czego nie powinno buforować), a także zarządzanie zawartością bufora (tj. Wyzwalanie czyszczenia pamięci podręcznej).

Nie polecam żadnego, chyba że masz pełne zrozumienie tego, co robisz. Źle skonfigurowane odwrotne serwery proxy mogą uszkodzić informacje nagłówka, mogą spowodować utratę sesji, udostępnianie sesji, nieaktualne treści, stosowanie dodatkowych limitów czasu ładowania / buforów, zużycie dodatkowych zasobów itp.

Pełny bufor strony

• EE FPC
• … Wiele innych (poprzez moduły)

Użyj jednego, jeśli to konieczne (tj. Nie w celu przyspieszenia wolnej witryny, ale w celu zmniejszenia zużycia zasobów w szybkiej witrynie).

W przeciwieństwie do powszechnego przekonania, możesz (i powinieneś) używać FPC w połączeniu z odwrotną pamięcią podręczną proxy. Oba rozwiązują różne problemy i mają różne możliwości.

FPC mogą wykorzystać więcej inteligencji, ponieważ mają bezpośredni dostęp do sesji użytkownika i rdzenia Magento, podczas gdy odwrotne proxy nie jest świadome aplikacji (jest dość głupie w działaniu) - więc oba uzupełniają się, nie konkurują ze sobą .

To znaczy. Nie myśl Lakier lub FPC, myśl Lakier i FPC.

Wybrałbym Redis + APC z lakierem na górze.

„Dlaczego Redis” pytasz? Przeczytaj tę doskonałą odpowiedź SO . Redis zasadniczo zastępuje standardowy system buforowania oparty na plikach Magento. Ponieważ Redis jest szybszy, da ci pewną poprawę prędkości.

Lakier nie ma tak wiele wspólnego z wewnętrznymi działaniami. Jest nakładany i buforuje zawartość statyczną, więc nigdy nie dociera do Magento jako żądanie. Z wyjątkiem części dziurkowanych, to znaczy.

Podczas gdy Varnish koncentruje się tylko na buforowaniu frontonu, Redis przyspieszy także inne typy pamięci podręcznej, takie jak pamięci podręczne EAV i konfiguracyjne.

Opcjonalnie możesz sprawdzić niektóre rozszerzenia Full Page Cache dla Magento zamiast Varnish. Chociaż nie jest tak szybki, ogólnie jest łatwiejszy do wdrożenia i nie polega na dodatkowym oprogramowaniu (takim jak Varnish)