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.
- Informacje o zapasach / cenach są nieaktualne do momentu unieważnienia lub wygaśnięcia TTL
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
- Nie masz wystarczającej liczby naturalnych kroków, aby utrzymać pamięć podręczną w stanie zapełnionym (patrz „Gdzie przydatny jest FPC”)
- 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
- Indeksowanie z szablonu (np. Mapa witryny)
- Wyodrębnij linki strona po stronie i zaindeksuj je
I jest wiele narzędzi do zrobienia obu z nich, niektóre z nich znam
- mag-perftest
- HTTrack
- Nutch
- Pająk
- 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