TL; DR - Trên MageStack, chúng tôi sử dụng Varnish, Redis (bộ đệm), Redis (phiên) và Eaccelerator / Zend OPCache (tùy thuộc vào phiên bản PHP)
Bạn đã hiểu hầu hết về nó.
Bộ đệm phụ, bộ lưu trữ phiên, bộ đệm opcode, bộ đệm toàn bộ trang và bộ đệm proxy ngược hoàn toàn khác nhau.
Bạn có thể sử dụng các công nghệ khác nhau cho tất cả và bạn có thể sử dụng chúng TẤT CẢ đồng thời (bao gồm cả Varnish và FPC)
Bộ đệm cuối bộ nhớ cache
- Tệp (Lõi) Mặc định
- Memcache (Lõi)
- APC (Lõi)
- Redis (<1.9 mô-đun lịch sự Colin Mollenhour)
- MongoDB (mô-đun lịch sự Colin Mollenhour)
- Rubic (mô-đun lịch sự Daniel Sloof)
Bạn chỉ có thể sử dụng một bộ đệm phụ.
Trái với suy nghĩ phổ biến, sử dụng bộ nhớ cache dựa trên bộ nhớ sẽ không cải thiện hiệu suất. Nhưng nó sẽ khắc phục một số lỗi nghiêm trọng trong bộ nhớ đệm dựa trên tệp mặc định của Magento.
Khi viết tin nhắn này, Redis là đề xuất của tôi.
Cửa hàng phiên
- Tệp (Lõi) Mặc định
- Memcache (Lõi)
- Redis (<1.9 mô-đun lịch sự Colin Mollenhour)
- MongoDB (mô-đun lịch sự Colin Mollenhour)
Bạn chỉ có thể sử dụng một cửa hàng phiên.
Trái với niềm tin phổ biến, sử dụng cửa hàng phiên dựa trên bộ nhớ sẽ không cải thiện hiệu suất.
Khi viết tin nhắn này, Redis là đề xuất của tôi.
Bộ nhớ cache OpCode
- APC
- XCache
- Eaccelerator (PHP <5.4)
- Zend OPCache (PHP> 5.4)
Bạn thực sự có thể cài đặt nhiều bộ đệm opcode, nhưng nó không được khuyến khích, tôi cũng không muốn thấy bất kỳ lợi ích nào.
Khuyến nghị của tôi là trong ngoặc ở trên.
Không có mô-đun được yêu cầu phải được cài đặt để tận dụng điều này.
Reverse Proxy Cache
- Véc ni
- Nginx
- Apache
- … và nhiều thứ khác nữa
Bạn có thể sử dụng nhiều proxy ngược và trong khi thực hiện việc này rất phức tạp và dễ bị kéo dài bộ đệm, nó có thể có giá trị (ví dụ: Để ngăn chặn việc đóng dấu trong quá trình xóa bộ đệm).
Sử dụng một khi cần thiết (ví dụ: Không phải để tăng tốc trang web chậm, nhưng để giảm mức sử dụng tài nguyên trên trang web nhanh).
Để tận dụng proxy ngược, nó cần cả cho phép phía máy chủ và cần một mô-đun cho Magento.
Lý do cho mô-đun là để giúp kiểm soát logic bộ đệm (nghĩa là Để nói cho bộ đệm biết những gì nên và không nên lưu vào bộ đệm) và cũng để quản lý nội dung bộ đệm (ví dụ: Để kích hoạt thanh lọc bộ đệm).
Tôi không khuyên bạn nên trừ khi bạn có sự hiểu biết hoàn toàn về những gì bạn đang làm. Thiết lập xấu proxy có thể phá vỡ thông tin tiêu đề, có thể gây mất phiên, chia sẻ phiên, nội dung cũ, áp dụng các giới hạn bổ sung để tải thời gian / bộ đệm, tiêu thụ tài nguyên bổ sung, v.v.
Cache toàn trang
- FPC EE
- Nhiều người khác (thông qua các mô-đun)
Sử dụng một khi cần thiết (ví dụ: Không phải để tăng tốc trang web chậm, nhưng để giảm mức sử dụng tài nguyên trên trang web nhanh).
Trái với suy nghĩ phổ biến, bạn có thể (và nên) sử dụng FPC kết hợp với bộ đệm proxy ngược. Hai người giải quyết các vấn đề khác nhau và có khả năng khác nhau.
Các FPC có thể tận dụng trí thông minh nhiều hơn, bởi vì họ có quyền truy cập trực tiếp vào phiên của người dùng và lõi của Magento, trong khi proxy ngược lại không nhận biết ứng dụng (nó khá ngu ngốc trong cách hoạt động) - vì vậy hai bên bổ sung cho nhau, không cạnh tranh với nhau .
I E. Đừng nghĩ Varnish hoặc FPC, hãy nghĩ Varnish và FPC.