Chúng tôi chỉ không - tất cả. Không bao giờ. Chúng tôi sẽ nói điều này nhiều lần nhưng
Bộ nhớ đệm! = Hiệu suất
Trang web của bạn cần phải nhanh chóng mà không cần thêm FPC (hoặc Varnish cho thực tế đó). Luôn luôn có một thời gian khi nội dung không được mồi (kịch bản của bạn ở trên).
Trên một cửa hàng không tải, thời gian tải trang với FPC không nên ấn tượng hơn nhiều so với không phải FPC; Magento khá hạnh phúc có khả năng < 400mstải thời gian tải trang trên bộ đệm tiêu chuẩn (trên danh mục / sản phẩm / trang tìm kiếm). FPC sẽ đưa nó xuống < 80ms- nhưng đi kèm với hãy cẩn thận.
- Thông tin về cổ phiếu / giá đã hết hạn cho đến khi hết hiệu lực hoặc hết hạn
Các mục mới / tìm kiếm phù hợp hơn đã hết hạn cho đến khi hết hiệu lực hoặc hết hạn
v.v.
Tại sao sự phụ thuộc vào FPC (hoặc Varnish) là một ý tưởng tồi
Nếu bạn đang tìm cách liên tục đảm bảo bộ nhớ cache được mồi theo cách thủ công, có thể có một vài lý do
- Bạn không có đủ lượng chân tự nhiên để giữ bộ nhớ đệm (xem 'Trường hợp FPC hữu ích')
- Trang web của bạn quá chậm mà không có họ
Bạn không thể lưu trữ mọi thứ
Nếu bạn có một cửa hàng chỉ với 5 danh mục, sâu 2 cấp độ lồng nhau, 5 thuộc tính có thể lọc, 5 tùy chọn thuộc tính mỗi loại và 1000 sản phẩm; đó là rất nhiều sự kết hợp có thể
25 tùy chọn để chọn, chọn tối đa 5 lần liên tiếp - Tôi không phải là người thống kê , nhưng tôi biết đó là ... (giả sử số lượng tùy chọn thuộc tính không giảm hoàn toàn)
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, như trên không phải là một kịch bản có thể xảy ra, như tôi tưởng tượng, trong vòng 3 lần nhấp - số lượng sản phẩm có sẵn sẽ giảm đủ để khách hàng tìm thấy sản phẩm của họ. Vì vậy, ngay cả khi đó là ...
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
Sau đó nhân với 5 loại, đó là 625 URL. Ở giai đoạn này, chúng ta đang nói về một danh mục nhỏ và hoàn toàn bỏ qua tất cả các URL của sản phẩm.
Chúng tôi cũng không bao gồm trong trường hợp nếu bạn có các danh mục lồng nhau is_anchor, nó sẽ tăng theo cấp số nhân.
Vì vậy, để thu thập số lượng trang đó - bạn phải hy vọng rằng thời gian tải trang của mình tốt và thấp, để đó là một quá trình nhẹ nhanh chóng (do đó đánh bại mục đích thu thập dữ liệu) - hoặc bạn có đủ thời gian để nó hoàn thành trước khi hết hạn.
Nếu các trang của bạn có thời gian tải trang là 0,4 giây và bạn có CPU 8 lõi - thì ...
625 * 0.4 = 250 / 8 = 31 seconds
0,5 phút, không tệ - nhưng hãy tưởng tượng bạn có thời gian tải trang 2 giây
625 * 2 = 1250 / 8 = 156 seconds
Nhưng nếu bạn lấy kịch bản tối đa có thể
3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes
Vì vậy, đó là máy chủ sản xuất của bạn, tải CPU dưới 100% trong 15 phút. Bạn sẽ giảm tốc độ thu thập dữ liệu theo tỷ lệ tương ứng với TTL mà bạn muốn.
Vì vậy, nếu bạn muốn nội dung có 3600 giây, thu thập thông tin có thể chậm hơn 4 lần - tức là. Chỉ 25% CPU dành riêng cho thu thập thông tin. Đó là rất nhiều tài nguyên chỉ để giữ nguyên nội dung danh mục - chúng tôi thậm chí chưa bao gồm các sản phẩm, cụm từ tìm kiếm hoặc lượt xem cửa hàng bổ sung trong giai đoạn này
Trên thực tế, chỉ cần nhìn vào kích thước tuyệt đối của các kết hợp trong catalog_url_rewritesbảng (thậm chí không bao gồm các tham số từ điều hướng được xếp lớp) sẽ cho bạn biết có bao nhiêu URL bạn có thể cần phải thu thập dữ liệu.
Mỗi cửa hàng chắc chắn sẽ khác nhau, nhưng điều tôi đang cố gắng tấn công là việc thu thập dữ liệu trang web đến FPC chính là không thực tế. Chỉ cần đảm bảo cửa hàng của bạn nhanh chóng để bắt đầu .
Trường hợp FPC hữu ích
Khi các lợi ích của FPC phát huy tác dụng là ở một cửa hàng được tải rất nhiều - nơi bạn có lưu lượng truy cập thực sự cao và các bộ nhớ cache được tự nhiên và liên tục được mồi bởi một mình.
FPC sau đó đi vào hoạt động bằng cách giảm chi phí cơ sở hạ tầng đối với nội dung thường được yêu cầu - cắt giảm các cuộc gọi lặp đi lặp lại đến phụ trợ Magento.
Vì vậy, chúng tôi thấy rằng FPC rất tốt để triển khai khi bạn có mức lưu lượng truy cập rất cao - không phải để giảm thời gian tải trang - mà là để giảm việc sử dụng tài nguyên.
Ai quan tâm, tôi vẫn muốn bò
Chà, sau đó bạn có hai lựa chọn
- Thu thập dữ liệu từ một mẫu (Ví dụ: sơ đồ trang web)
- Trích xuất liên kết từng trang và thu thập dữ liệu từng trang
Và có nhiều tiện ích để làm cả hai điều này, đây là một số tiện ích tôi biết
- pháp sư
- HTTrack
- Nạng
- Người hướng dẫn
- Trình thu thập thông tin4j
Sử dụng Mage-Perftest
Bạn có thể thu thập dữ liệu cửa hàng của mình với Mage-Perftest khá dễ dàng, trước tiên hãy tải xuống
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*
Sau đó, xác định quy trình thu thập thông tin bằng sơ đồ trang web Magento (bạn có thể tùy chỉnh điều này bằng cách tạo sơ đồ trang web của bất kỳ URL nào, miễn là các url được gói trong <loc></loc>thẻ). Lệnh sau sẽ đọc tất cả các URL từ tệp sơ đồ trang web, sau đó thu thập dữ liệu (chỉ PHP) các URL trong vòng 1440 phút (1 ngày). Nếu máy chủ vượt quá 20% CPU hoặc trung bình tải là 2 - thì việc thu thập thông tin sẽ tạm thời dừng lại.
./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2
Nếu bạn có 1000 URL, được thu thập thông tin trong hơn 1 ngày, đó sẽ là khoảng. 1 yêu cầu cứ sau 86 giây (s) ~ mục tiêu 0,011 RPS