Thông tin chi tiết bộ nhớ đệm Magento

Chúng tôi đang chạy Magento EE 1.11 với memcache. 2GB cho mỗi máy chủ memcahce, tổng cộng 4GB. Chúng tôi có khoảng 240k sản phẩm.

• Ram có sẵn: 6GB
• Lõi: 16
• Chủ đề: 32

Đây là thỏa thuận, nhiều sản phẩm mới được thêm vào và thay đổi sản phẩm xảy ra hàng ngày và tất nhiên mỗi khi một sản phẩm mới được thêm / sửa đổi ở mặt sau, bộ đệm sẽ bị vô hiệu, cụ thể là 'Bộ đệm toàn trang'.

Khi Magentos Auto Cache Generation được bật, sẽ mất khoảng 2 ngày để xây dựng bộ đệm, với 8 luồng được phân bổ cho trình thu thập thông tin. Sau 2 ngày, memcache nổi xung quanh ~ 2GB được phân tách giữa hai đĩa ram.

Vấn đề là, khi các sản phẩm được sửa đổi hàng ngày, bộ đệm sẽ bị vô hiệu hóa và ngay sau khi 'Bộ nhớ cache toàn trang' được làm mới, 2GB bộ nhớ cache đó đã trở lại hình vuông một, 0 và chu kỳ nhớt của bộ đệm tự động Magentos bắt đầu lại. Giờ đây, không chỉ bộ nhớ cache trở về 0, mà mức sử dụng CPU tăng vọt lên 90% và trang web biến thành trò chơi chờ 5-10 giây và bạn có thể quên việc cố gắng yêu cầu một sản phẩm có hơn 100 biến thể, nếu đó là không được lưu vào bộ nhớ cache, sẽ mất vài phút để tải lần đầu tiên, thật nực cười.

Vì vậy, câu hỏi của tôi cho cộng đồng.

• Có cách nào để Magento tự động "cập nhật" bộ đệm nếu không hợp lệ, mà không xây dựng lại toàn bộ bộ đệm và bắt đầu từ 0 không? Tôi biết khi bộ đệm bị vô hiệu hóa mà Magento biết đôi khi đã thay đổi, nhưng không chính xác vị trí trong bộ đệm (sửa tôi nếu tôi sai). Có các mô-đun / cấu hình ngoài đó để bỏ qua việc xây dựng lại toàn bộ bộ đệm?

Bên cạnh đó, chúng tôi đang sử dụng mô-đun Tiny Bricks LightSpeed.

• Magentos Automatic Cache Generation có thể được kiểm soát thời gian bằng cronjob không? Nói, để bắt đầu bò lúc 10 giờ tối - 6 giờ sáng.

• Điều gì sẽ là cách tốt nhất để tiếp cận tình huống này?, Như bạn hiểu, việc xây dựng lại bộ đệm mà tính bằng gigabyte mỗi ngày là không thể chấp nhận được.

Bạn không có đủ RAM

Chúng tôi có khoảng 240k sản phẩm
Có sẵn ram: 6GB
Chủ đề: 32

Bạn không có đủ RAM cho số lượng sản phẩm bạn có. Theo nguyên tắc thông thường, chúng tôi khuyên dùng ít nhất 2-4 GB RAM cho mỗi lõi logic.

Nếu bạn vạch ra việc sử dụng bộ nhớ có thể của bạn:

• 64 Chủ đề PHP có max_memory~ 768MB = 24GB
• 240.000 Sản phẩm có thể có nghĩa là khoảng 15 GB không gian bảng InnoDB
• 64 Chủ đề PHP sẽ đảm bảo khoảng 128 kết nối MySQL, thông thường, điều này có chi phí khoảng 200 MB cho mỗi kết nối tối thiểu
• Bộ nhớ cuối cho 240.000 sản phẩm trong Redis VÀ được lzfnén - vẫn sẽ tiêu tốn khoảng 6GB RAM

Vì vậy, tổng số cho đến nay là 70GB RAM cam kết - chúng tôi thậm chí không đề cập đến HĐH, v.v.

Phần cứng của bạn không được đánh giá đúng mức . Tôi sẽ đề nghị đọc qua máy chủ Magento này để thiết lập bài viết cho một chút cảm nhận về cách tiến bộ.

Memcached không hỗ trợ thẻ bộ nhớ cache

Nếu bạn đang sử dụng Memcached (không phải là vấn đề, hiệu năng rất cao), thì bạn có lưu trữ thẻ bộ nhớ cache hay không. Nếu bạn chưa slow_backendxác định - thì bạn không lưu trữ thẻ, điều đó có nghĩa là bộ đệm của bạn không thể phân biệt giữa bất kỳ loại bộ đệm nào khác nhau - vì vậy bạn sẽ không thể xóa chúng một cách độc lập.

Hãy đọc qua điều này, http://www.sonassi.com/ledgeledge-base/magento-kb/what-is-memcache-actingly-caching-in-magento/

Chúng tôi thực sự khuyên bạn nên chuyển sang Redis. Nó có những đặc điểm riêng và không cần tinh chỉnh đáng kể cho các cửa hàng lớn hơn. Nhưng nói chung sẽ hoạt động tốt hơn một chút so với Memcached với lợi ích thực sự của hỗ trợ thẻ nhớ cache.

404 và FPC

FPC có một vấn đề thực sự, trên thực tế, tất cả các công cụ lưu trữ đều có vấn đề với 404s. Lý do là, bất kỳ URL cũ nào vẫn được thu thập hoặc liên kết đến sẽ nằm trên một trang phải lặp qua toàn bộ core_url_rewritebảng, thử và tìm một kết quả khớp với tất cả các bộ định tuyến và không gian tên được xác định trước khi cuối cùng bỏ và tải 404.

Sau đó, lưu trữ tài nguyên không có giá trị và sẽ tiêu tốn dung lượng trong bộ nhớ cache của bạn. Bạn có thể sẽ thấy một tỷ lệ lớn dung lượng lưu trữ Memcached của bạn đang thực sự bị ăn bởi nội dung 404.

Với các danh mục lớn (240k sản phẩm), bạn chắc chắn sẽ có phần doanh thu sản phẩm hợp lý, và do đó, thay đổi trong URL và sau đó, nhiều 404.

FPC không hợp lệ so với sạch

Hiện tại - và theo mặc định - hành vi của FPC là làm sạch bộ đệm khi thay đổi, thay vì chỉ làm mất hiệu lực mục nhập bộ đệm. Chúng tôi đã viết một phần mở rộng để thay đổi hành vi này cho một cửa hàng EE để làm chính xác những gì bạn yêu cầu.

Đây là một bản vá nhanh để cung cấp cho bạn ý tưởng về cách giải quyết vấn đề của bạn.

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>

Đừng chạy trình thu thập thông tin

Nếu bạn đã có đủ số lượng chân - chúng tôi không khuyên bạn nên chạy công cụ thu thập thông tin, nó sẽ tạo ra tải không cần thiết. Mọi người / bot / trình thu thập thông tin duyệt trang web nên giữ nguyên bộ đệm.

Nhưng để trả lời câu hỏi của bạn, nếu bạn xem trong tệp cấu hình được đề cập ở trên - bạn sẽ thấy lịch trình cron đã được xác định cho cửa sổ duyệt tìm thu thập thông tin.

Nếu bạn có thể đủ khả năng nội dung cũ

Và cuối cùng, nếu bạn có đủ RAM. Bạn cũng có thể hưởng lợi từ việc tăng TTL nội dung được lưu trữ trong FPC - để giữ cho dữ liệu được lưu trong bộ nhớ cache của bạn tồn tại lâu hơn.

Trong <full_page_cache>thẻ bạn ./app/etc/local.xmlchỉ cần xác định

<lifetimelimit>86400</lifetimelimit>

Tuổi thọ được xác định bằng giây. Bạn cần đạt được sự cân bằng giữa độ mới của nội dung, hiệu suất và dung lượng lưu trữ bạn thực sự có sẵn.

Tại sao bạn sử dụng tiện ích mở rộng bộ nhớ đệm của bên thứ 3 với EE

Bạn đang trả phí bảo hiểm cho FPC - điều làm tôi đau lòng, là rất tốt. Vậy tại sao bạn chạy các lựa chọn thay thế của bên thứ 3 trên đầu trang. Gỡ bỏ nó.

Đặt nó theo cách này. Nếu xe của bạn chạy không tốt - bạn có thể thêm một động cơ khác vào khởi động để bù lại; hoặc chỉ sửa chữa động cơ đã có trong đó?

Chúng tôi hiểu bạn rất rõ! Chúng tôi thêm mới hoặc thay đổi sản phẩm của mình mỗi ngày và sửa đổi các khối tĩnh. Vì vậy, chúng tôi đã đầy đủ với bộ đệm Magento không hợp lệ và liên tục này sẽ chuyển sang Hệ thống -> Quản lý bộ đệm. Chúng tôi ghét sự cần thiết phải làm mới các loại bộ đệm không hợp lệ bằng tay.

Sau đó, chúng tôi đã cài đặt tiện ích mở rộng Magento Tối ưu hóa mới . Mô-đun này tự động hóa quá trình này. Nó làm mới không hợp lệ / tất cả các loại bộ đệm hoặc xóa bộ nhớ cache Magento ở tần số đã chỉ định. Đó là một cứu trợ thực sự cho tất cả các đội của chúng tôi!

Một tính năng tuyệt vời nữa của tiện ích mở rộng này là nó dọn sạch các tệp phiên và báo cáo lỗi cũ hơn X ngày. Mọi người đều biết rằng kích thước của các thư mục var / session và var / báo cáo có thể tăng lên thành gigabyte và số lượng các tệp này có thể vượt quá trăm. Vì vậy, bây giờ để làm chậm hiệu suất trang web, chúng tôi đã thiết lập Trình tối ưu hóa Magento một lần và quên đi việc làm mới định kỳ các thư mục này.

Magento được biết đến với việc hợp nhất một giỏ hàng bị bỏ rơi với giỏ hàng hiện tại khi khách hàng cố gắng đăng nhập. Từ quan điểm của khách hàng và quan điểm về lòng trung thành, nó mang tính hủy diệt. Mô-đun tối ưu hóa Magento tự động xóa các giỏ hàng bị bỏ rơi cũ hơn X ngày. Bạn cũng có thể sử dụng tính năng này tại thời điểm bán hàng và giới hạn thời gian cho các giỏ hàng bị bỏ rơi hiện có.