Jestem trochę zdezorientowany, gdy zaczynam badać Full Page Caching dla Community Edition 1.8. Wdrożyłem już dwupoziomową pamięć podręczną Redis, CDN, dostroiłem my.cnf MySQL pod kątem maksymalnej wydajności (oczywiście z DB znajdującym się na osobnym serwerze) i mam 2 serwery hostujące nasz sklep za modułem równoważenia obciążenia. Mówię to, aby podkreślić, że nie od razu skaczę do FPC przed dokonaniem wstępnych poprawek wydajności.
Nigdy wcześniej nie używałem Varnish na żadnej stronie, nie mówiąc już o Magento, i nigdy nie stworzyłem FPC w Magento. Rozumiem, że Varnish jest serwerem proxy, który działa jako połączenie CDN i pamięci podręcznej strony, wysyłając dane do przeglądarki, zanim żądanie dotrze nawet do serwera WWW. I o ile mi wiadomo, moduł FPC tworzy lokalnie pamięć podręczną, którą sam serwer WWW wyrzuca. Wiem, że w obu konfiguracjach musisz wykonać kilka „dziurkowania”, aby przenieść zawartość dynamiczną do przeglądarki (chociaż techniki są różne, między użyciem modułu lub użyciem lakieru). Popraw mnie, jeśli coś tu nie rozumiem.
Do tej pory myślałem o nich jako o dwóch osobnych podmiotach, które można wdrożyć, aby pomóc w tworzeniu witryny, ale teraz coś, co przeczytałem, wydaje się sugerować coś przeciwnego. Mój pierwotny plan polegał na zakupie modułu „ Warp Advanced Full Page Cache ” dla Magento (dawniej „Tiny Brick Lightspeed FPC”, jak sądzę), ponieważ wydaje się on najbardziej popularny, jeśli dotknie go droższa strona (ale, szczerze mówiąc, 350 USD to niewiele dla naszej firmy, zwłaszcza za to, co może zrobić). Ja i 2 moich programistów planowaliśmy nauczyć się, jak prawidłowo i w pełni wdrożyć go w naszym własnym, domowym motywie, aby zmaksymalizować to, co możemy z niego uzyskać. Po tym, jak to zrobiłem, w pewnym momencie na drodze, pomyślałem, że będę również rozważał wdrożenie Lakieru - ale, jak powiedziałem wcześniej, zrozumiałem, że są one oddzielne.
Teraz jednak zaczynam spotykać się z takimi rozszerzeniami, jak ten PageCache Powered by Varnish, który jest bezpłatny, lub ten Vortex Cache Powered by Varnish Cache, który kosztuje prawie 800 USD, czyli moduły Magento Full Page Cache, które współpracują bezpośrednio z Varnish.
Moje pytanie do ciebie, zamianie stosów, to jak powinienem widzieć FPC i lakier? Jako odrębne podmioty? Jeśli tak, to czy wykluczają się wzajemnie? Czy to dwie strony tej samej monety, którą powinienem wspólnie wdrożyć? A może są do siebie podobne, ale nie wykluczają się nawzajem?
Czy mogę używać Warp Advanced FPC, o którym wspomniałem powyżej, do lakieru? Czy powinienem używać go z lakierem? Czy może lepiej byłoby użyć innego FPC, jeśli planuję używać lakieru? LUB jeszcze dalej, czy FPC jest tak dobry, że nie potrzebuję lakieru? Lub odwrotnie, czy powinienem po prostu użyć lakieru i porzucić pomysł FPC?
Przepraszam za ścianę tekstu, ale oglądałem wiele artykułów, blogów i postów na forum i nie byłem w stanie znaleźć ostatecznej odpowiedzi na te pytania. Naprawdę doceniam twoją pomoc i wkład w tę sprawę =)
No i na koniec krótkie pytanie o Lakier i serwery internetowe. Obecnie używam normalnej konfiguracji stosu Apache LAMP, ale od pewnego czasu widzę, jak ludzie zachwycają się używaniem Nginx z Magento. Sam wykonałem kilka testów, testów obciążeniowych i obciążeniowych, i wydaje się, że zdecydowanie może działać nieco lepiej w odpowiednich warunkach. Jako taki, rozważałem zmianę w pewnym momencie w najbliższej przyszłości. Czy to i tak wpłynęłoby na moją chęć i decyzję o użyciu FPC i / lub Lakieru?
Dziękuję Ci!!!
EDYCJA: Och! I jeszcze jedno szybkie pytanie - ponieważ mam dwa serwery hostujące moją witrynę za modułem równoważenia obciążenia (który jest również konfiguracją, którą można zwiększyć w poziomie, jeśli zajdzie taka potrzeba), w pełni wykorzystuję Redis i Memcached hostowane na innym serwerze niż Web i DB dla moich sesji i każdego poziomu Dwupoziomowej pamięci podręcznej Magento (cóż, Zend). Zakładam, że FPC przechowałby swoje dane w jednym z tych systemów? Czy muszę mieć określone rozszerzenie, aby je tam przechowywać, czy wszyscy to robią? I choć nie zakładam, czy to i tak wpłynęłoby na Lakier? Dzięki jeszcze raz!!
źródło
Odpowiedzi:
W informatyce istnieją dwie trudne rzeczy:
Dziurkowanie należy do kategorii nr 2 :)
Generał
Najlepszym podejściem jest zacząć od niższych punktów stosu i zoptymalizować do frontendu Magento.
Baza danych i system plików
Zawsze powinny być pierwsze obszary, na których należy się skupić. Bo. I / O.
MyTop to przydatny skrypt perlowy oparty na Linuksie, który naśladuje polecenie „top” Linuksa i daje wgląd w stan twoich instancji MySQL.
Htop jest bardziej niezawodny. Funkcja strace może pomóc określić wejścia / wyjścia procesu w celu znalezienia potencjalnych wąskich gardeł.
Iotop to kolejne narzędzie do monitorowania we / wy.
Inne przydatne skrypty narzędziowe, takie jak mysqltuner.pl i mysql tuning primer, mogą oferować wgląd w zmienne środowiska wykonawczego MySQL oraz porady, które mogą pomóc. Należy pamiętać, że mają one stanowić wytyczne, ponieważ najlepszym podejściem jest zawsze ocena wymagań i dostosowanie na podstawie zebranych znanych danych. Ślepe postępowanie może czasami powodować więcej obrażeń niż pożytku. Przedwczesne ich uruchomienie bez co najmniej 24 godzin zmiennych wykonawczych mysql może dawać złe porady.
Pamiętaj, że Percona , MariaDB i standardowy MySQL powinny działać z wszystkimi powyższymi. Preferowanie Percona jako widelca MySQL, ponieważ Magento jest tak ciężki dla InnoDB, a XtraDB oferuje wiele narzędzi i ulepszeń silnika db.
Apache lub Nginx
Nadal używam Apache, ponieważ dobrze służył wielu innym, w tym mnie. Użyłem i skonfigurowałem również Nginx. Chociaż oferuje pewne zalety, istnieje krzywa uczenia się. Obie są popularnymi opcjami, ale oferują pewne zalety w stosunku do Apache, jedną z nich byłby mniejszy ślad pamięci. Jednak niewielki Apache z PHP-FPM będzie miał podobny ślad pamięci.
Przykładem:
Aby ułatwić to sprawdzenie:
Wykorzystanie CDN do ułatwienia obu pomoże oczywiście, ale przyniesie dodatkowe korzyści w zakresie optymalizacji interfejsu, ponieważ większość przeglądarek użytkowników końcowych będzie mogła połączyć się z obydwoma serwerami przy tej samej liczbie limitów połączeń. To także uwalnia Apache'a od konieczności przeskakiwania czeków i po prostu wyświetlania prostego statycznego obrazu. Lighthttpd jest opcją, jeśli chcesz uruchomić statyczny serwer WWW tylko dla zawartości poza CDN.
PHP
PHP-FPM i APC. Używaj ich, usuwaj niepotrzebne lub niepotrzebne moduły PHP, które nie są potrzebne Magento.
Baza kodu Magento
AOE_TemplateHints doskonale sprawdza się, czy Twoje bloki są buforowane poprawnie:
AOE_Profiler jest dobry do profilowania, upewnij się i włącz profilowanie jego warstwy DB (oczywiście w środowisku lokalnym / deweloperskim). To w połączeniu ze wspomnianym wcześniej narzędziem mytop ułatwia znalezienie źle zachowującego się SQL.
Moduły stron trzecich i niestandardowy kod
Niektóre bardzo dobre sprawdzone metody optymalizacji od samego Magento to dobra lektura i należy o tym pamiętać, przeglądając moduły innych firm przed ich użyciem. (istnieje wiele źle zachowujących się IMO).
Narzędzie Magniffer z Magento ECG pomoże łatwo zidentyfikować źle zachowujący się kod na podstawie powyższego pliku PDF. Jest jednak oparty na symfony / php-parserze, ale można go zainstalować za pomocą kompozytora.
Lakier
Jako zwolennik Varnish jako autora jądra FreeBSD, oferuje on szalone czasy ładowania poniżej sekundy. Jednak jeśli masz nawet najmniejsze różnice w szablonach, które nie są gotowe, poświęcisz czas na konfigurację lakieru / magento w celu wprowadzenia potrzebnej zawartości. Większość, które widziałem, po prostu AJAX'ify potrzebne przedmioty, które nie zostały odłączone od Lakieru.
Istnieje wiele modułów Magento, które ułatwiają dziurkowanie i buforowanie:
Ostatecznie powinno to być na ostatnim końcu podróży optymalizacyjnej i MOŻE wymagać pewnych dostosowań, aby wszystko było w porządku.
Magento CE FPC
Jak dotąd najlepszym CE FPC, jaki znalazłem, jest: Lesti :: FPC
jest to bardzo dobrze zestawiony (oparty na wszystkich obserwatorach) open source i darmowy FPC dla społeczności.
Na koniec dnia skorzystaj z własnych testów i osądu.
Dalsza lektura:
źródło
Nieco późno do tego wątku, wiem, ale jeśli wciąż szukasz rozwiązania, możesz rozważyć Evolved Caching . Jest to ta sama cena co Warp, ale:
Konfiguracja za pomocą Varnish jest prosta, wystarczy włączyć ustawienie administratora i użyć znajdującego się tutaj .vcl . Nie jesteś ograniczony do Lakieru obsługującego pamięć podręczną tylko wtedy, gdy nie ma żadnych plików cookie, jak zwykle - masz bardzo wysoki współczynnik trafień w pamięci podręcznej.
źródło
Napisaliśmy FPC, który jest zgodny z nowym kluczem formularza Magento 1.8. Pełna pamięć podręczna strony Brim: http://ecommerce.brimllc.com/full-page-cache-magento.html
BOOMER ma wielką zaletę, gdy zaczyna się od niskiego stacka i rozwija się. FPC lub Lakier powinny być ostatnie. Przeprowadzamy audyty wydajności i często znajdujemy problemy z konfiguracjami MySQL i APC, które są naprawdę wyłączone. Jak bufory Innodb ustawione na domyślne, a baza danych znacznie się rozrosła.
Odradzamy stosowanie jakichkolwiek FPC z lakierem, chyba że są specjalnie zaprojektowane do współpracy. Zasadniczo nie zalecamy Varnish, chyba że masz garść mocnych serwerów, które wszystkie zostały dostrojone wraz z bazą kodu i nadal mają problemy z utrzymaniem ruchu. Aktualizowanie zawartości dynamicznej może być trudne przy użyciu Varnish, szczególnie w przypadku próby ograniczenia żądań do zaplecza Magento, a tym samym zmniejszenia obciążenia. Jeśli masz jedną lub dwie głowice, zyski mogą nie być warte czasu i komplikacji.
W większości sytuacji dobry FPC zapewni Ci wydajność, jakiej potrzebujesz, oczywiście po dostrojeniu serwera i bazy kodu. Dzięki naszemu FPC możesz uzyskać czasy generowania sub 15ms dla pamięci podręcznej poziomu 1 i sub 100ms dla standardowej pamięci podręcznej. Nasza pamięć podręczna poziomu 1 jest używana w przypadkach, gdy użytkownik nie jest zalogowany i nie ma nic w koszyku, ponieważ nie wykonuje dziurkowania. Gdy którykolwiek z tych warunków jest fałszywy, używana jest standardowa pamięć podręczna z pełną obsługą dziurkowania.
Nasz FPC ma wbudowane łatwe wykrawanie otworów i działa po wyjęciu z pudełka ze wszystkimi standardowymi blokami Magento, a także dowolnymi niestandardowymi blokami. Wszystko to można skonfigurować za pomocą panelu administracyjnego.
Polecam pozostanie przy Redis, chyba że masz z tym problemy ze skalowaniem. Obsługuje tagi i jest znacznie szybszy niż memcached z plikiem lub bazą danych jako powolnym backendem. Jeśli chcesz mieć spójne tagi i czyszczenie, musisz użyć memcached z bazą danych, jeśli masz wiele głowic internetowych. Dzięki wbudowanej obsłudze tagów Redis nie musisz się o to martwić. Możesz także użyć Redis do swoich sesji.
Mogę mówić za wszystkich FPC, ale u nas możesz skonfigurować przez administratora, gdzie je przechowywać. Możesz wybrać użycie domyślnego zaplecza pamięci podręcznej Magento lub określić niestandardowe ustawienia korzystania z plików, bazy danych, APC, Redis, Memcache i zoptymalizowanego zaplecza plików.
źródło
Nie ma poprawnej odpowiedzi. Sklep powinien mieć dynamiczne ładowanie strony poniżej 3s, a najlepiej dynamiczne ładowanie strony 1-2s, sekunda sekundowa nie jest konieczna i jest to przede wszystkim statystyka marketingowa. Apache jest łatwy do nauczenia i trudny do wykonania, Nginx jest trudny do nauczenia i łatwy do wykonania, wiele stron przenosi się do Nginx, jednak posiadanie wysokiej jakości architektury opartej na Nginx i Magento nie jest proste.
Wieloportowe klastry Magento są już skomplikowane do wdrożenia, a nawet trudniejsze do utrzymania, jeśli nie mają właściwej architektury, zwykle pracujemy z większymi klastrami, co sprawia, że wszystko działa płynniej, w tym w rankingu. Robimy to ze standardową konfiguracją instalacji z niewielkimi zmianami dla średnio- i długoterminowej stabilności ukierunkowanymi na dynamiczne ładowanie stron 1-2s, dzięki czemu wszystko jest znacznie prostsze w konserwacji.
Lakier może być między innymi FPC, CDN, jednak w twoim przypadku najlepiej myśleć o nim jako FPC. FPC pozwala większej liczbie odwiedzających na serwerze i zapewnia szybsze dostarczanie statyczne, którego Lakier jest jednym z takich narzędzi, jednak występują z nim różne problemy, w tym dynamiczna zawartość, kontrola zapasów, ceny. Odpowiedź sprowadza się do struktury Twojej firmy, sposobu wczytywania danych, częstotliwości, typu hostingu itp., Po prostu dotyczy to Twojej firmy poprzez dostarczanie statycznych treści odwiedzającym. Technicznie można to znacznie złagodzić dzięki konfiguracji FPC, jednak komplikuje to środowisko biznesowe, z punktu widzenia właściciela firmy może nie generować zrównoważonego zwrotu z inwestycji.
FPC jest ostatnią częścią, jeśli masz ładowanie dynamiczne poniżej 3s lub lepiej, twoja architektura może obsłużyć perełkę w żądaniach gości, ponieważ wpływa to na ranking, absorbuje skoki marketingowe i wakacyjne, a także ma budżet na zwiększenie złożoności architektury serwera - hosting powinien wynosić 0,5 -1% przychodów dla mniejszych firm, z których większość generuje znaczne straty, powodując wiele pośrednich problemów biznesowych.
Powodem, dla którego nie znalazłeś ostatecznej odpowiedzi, jest fakt, że odpowiedzi na te pytania trwają miesiące, ponieważ są jakościowe (oparte na biznesie), które wymagają informacji, których firma nie chciałaby publikować publicznie, prędkości ładowania strony są ilościowe (oparte na danych technicznych ), które można opublikować, to właśnie sposób na połączenie tych dwóch rozwiązań.
źródło
Możesz użyć tej pamięci podręcznej strony Magento, która będzie pasować do twoich potrzeb i jest podobna do lakieru. Jest używany przez wiele największych sklepów Magento. Niektóre funkcje:
Jako wielopoziomowa pamięć podręczna jest skalowalna nawet dla sklepów o najwyższym natężeniu ruchu i była używana w wielu witrynach o bardzo dużym natężeniu ruchu, które otrzymują szczytowy ruch, takich jak sklepy prezentowane w SharkTank (program telewizyjny)
źródło