Xem chiến lược bộ đệm - mối quan hệ giữa bộ đệm truy vấn và bộ đệm đầu ra được kết xuất

Trước hết, tôi đang cố gắng đảm bảo sự siêng năng và không trùng lặp các câu hỏi đã được đưa ra trước đó. Có rất nhiều bài đăng trên stackexchange và nhiều nơi khác, thảo luận về bộ nhớ đệm xem và thậm chí một số chi tiết cụ thể về các loại bộ đệm xem khác nhau (ví dụ: ở đây và ở đây ). Tuy nhiên, tôi vẫn chưa tìm thấy bất kỳ chi tiết nào giải thích đầy đủ mối quan hệ giữa các lớp bộ nhớ đệm khác nhau và cách chúng có thể ảnh hưởng đến các quyết định bộ nhớ đệm theo trường hợp cụ thể. Để đơn giản, tôi cũng tập trung phạm vi của câu hỏi này vào các tùy chọn bộ đệm ngoài 7.x-3.x độc lập với các lớp khác được cung cấp trong không gian đóng góp.

Lượt xem hiển thị 2 lớp bộ đệm theo thời gian cho mỗi màn hình, bộ đệm "kết quả truy vấn" và bộ đệm "kết xuất đầu ra". Các chi tiết cụ thể về dữ liệu thô mà mỗi bộ đệm bao gồm là rõ ràng, nhưng cách chúng tương tác thì không. Tôi đặc biệt tự hỏi nếu một lần nhấn vào bộ đệm được kết xuất sẽ bỏ qua hoàn toàn họ truy vấn bộ đệm, hoặc nếu 2 lớp hoạt động riêng biệt. Tôi đã thấy một số tài liệu tham khảo yêu cầu cái trước (như cái này ), và một số cái yêu cầu cái sau (như cái này ).

Lý thuyết 1 - Các lớp bộ đệm riêng biệt

Ban đầu, tôi có ấn tượng (và hy vọng) rằng mỗi lớp được gọi riêng "theo chuỗi" và bộ đệm đầu ra được kết xuất sẽ băm kết quả truy vấn thực tế trong các hộp của nó. Bằng cách này tôi sẽ có một cách thanh lịch để cache đắt nhất sau truy vấn tải / xây dựng công trình, trong khi vẫn đảm bảo nội dung mới ngay lập tức được phản ánh trong giao diện ( "Kết quả truy vấn" cache tắt và "đầu ra trả lại" bộ nhớ cache trên ). Một số thử nghiệm nhanh cho thấy rằng điều này có thể không thực hiện được, vì bộ đệm đầu ra được kết xuất có thể không nhận thức được kết quả truy vấn hiện tại.

Lý thuyết 2 - Bộ đệm kết xuất truy vấn "bao gồm" bộ đệm kết quả truy vấn

Khả năng khác là bộ đệm kết quả được kết xuất được khóa bằng hàm băm của chính truy vấn (không phải kết quả). Nếu đây là trường hợp, một lần nhấn vào nó có thể trả về kết quả đầu ra được kết xuất trực tiếp mà không cần tham khảo bộ đệm truy vấn hoặc DB. Nếu đây là trường hợp thì tôi cho rằng sẽ không có ý nghĩa gì khi đặt bộ đệm "kết quả truy vấn" với khoảng thời gian nhỏ hơn bộ đệm "kết quả được hiển thị". Ưu điểm của khóa học là người ta có thể làm mới đầu ra được kết xuất thường xuyên hơn (nếu họ có nhiều logic chủ đề động hoặc cập nhật thực thể thường xuyên), trong khi vẫn tránh các truy vấn trực tiếp đến DB. Tuy nhiên, đối với tất cả các truy vấn chế độ xem phức tạp nhất, loại phân tách này có vẻ không thuận lợi lắm.

Tôi đã thực hiện một số thử nghiệm "hộp đen" chỉ ra lý thuyết 2, nhưng tôi không chắc liệu có một số cài đặt khác có thể đang chơi hay không nếu câu trả lời khác nhau theo phiên bản xem. Tôi cũng đã khám phá mã một chút, nhưng tôi cảm thấy bực bội vì các phương thức plugin của hầu hết các lượt xem đều không có giấy tờ và đôi khi khó theo dõi. Không có vấn đề gì, tôi nghĩ rằng câu trả lời cho điều này sẽ hữu ích khi có một tài liệu tham khảo cho người khác.

Tôi đã xem xét một số logic quan điểm nội bộ, và từ những gì tôi có thể có các yếu tố từ mỗi lý thuyết là chính xác, nhưng cả hai đều không chính xác 100%. Dường như cả hai lớp bộ đệm đều riêng biệt và luôn được kiểm tra theo chuỗi, do đó, bộ đệm "đầu ra được kết xuất" không thực sự có khả năng "bỏ qua" lớp truy vấn. Ngoài ra, kết quả truy vấn không ảnh hưởng đến bất kỳ khóa bộ đệm nào, do đó, thay đổi thành kết quả truy vấn không may không kích hoạt làm mới trong đầu ra được kết xuất.

7.x-3.x

Bộ đệm "kết quả truy vấn" được quản lý view::execute()và bộ đệm "kết xuất đầu ra" được quản lý view::render(). Vì execute()được gọi trước logic bộ đệm "đầu ra được kết xuất", nên nhấn bộ đệm "đầu ra được kết xuất" không thể bỏ qua lớp truy vấn. Tôi không hoàn toàn rõ ràng tại sao điều này có vẻ hơi lãng phí khi chạy truy vấn hoặc thậm chí kiểm tra bộ đệm truy vấn, nếu màn hình sẽ được tích hợp đầy đủ từ bộ đệm. Tôi nghi ngờ rằng có rất nhiều logic khác trong view::execute()(kiểm tra truy cập, hook, quản lý plugin) phải luôn được chạy độc lập với bộ đệm và phần bộ đệm "kết quả truy vấn" không thể tách rời khỏi nó. Dù sao, chi tiết đó là một chút tiếp xúc với câu hỏi, nhưng có lẽ ai đó sẽ có thể nhận xét về nó.

Về mặt các khóa bộ đệm, cả hai lớp bộ đệm đều được khóa theo tên xem, tên hiển thị, loại bộ đệm và sau đó là hàm băm của một "nội dung" theo ngữ cảnh views_plugin_cache::get_cache_key(). Nhìn vào get_cache_key()phương pháp này là sâu sắc vì nó cho thấy rằng một số dữ liệu theo ngữ cảnh phổ biến luôn được bao gồm (vai trò người dùng, ngôn ngữ, base_url), nhưng trường hợp "đầu ra được kết xuất" đưa mọi thứ đi xa hơn một chút bằng cách băm chuỗi truy vấn thô, nhưng không phải là kết quả truy vấn. Vì vậy, nếu truy vấn thô thay đổi, đầu ra được kết xuất sẽ được làm mới, nhưng nếu kết quả truy vấn thay đổi, đầu ra được kết xuất vẫn sẽ được trả về từ bộ đệm.

Vì vậy, tôi nghĩ rằng từ góc độ hiệu suất, mỗi lớp bộ đệm thực sự có thể được xử lý độc lập, nhưng bộ đệm "đầu ra được kết xuất" vẫn sẽ chi phối trực tiếp nhất tần suất hiển thị của dữ liệu "cũ". Tôi có thể kết luận thêm rằng:

• Khoảng thời gian làm mới cho danh sách cơ sở của các mục trong chế độ xem lớn hơn hoặc bằng với bất kỳ khoảng thời gian bộ đệm nào lớn hơn (danh sách thực tế của các mục không thể cập nhật cho đến khi cả hai bộ đệm hết hạn cho bất kỳ chế độ xem cụ thể nào).
• Nếu bộ đệm "đầu ra được kết xuất" cho chế độ xem đã cho sẽ làm mới trước bộ đệm "kết quả truy vấn", danh sách các mục sẽ không được làm mới, nhưng nội dung được hiển thị cho từng mục có thể (tức là một mục mới được thêm vào danh sách 5 giây trước sẽ không được hiển thị, nhưng văn bản trêu ghẹo đã được cập nhật 5 giây trước trên một mục trong danh sách trước đó sẽ cập nhật).
• Ngay cả khi bộ đệm "kết quả truy vấn" không ảnh hưởng đến đầu ra cuối cùng, nó vẫn cung cấp hiệu suất tăng cho view::execute().

Cũng đáng lưu ý rằng một số hành vi này có thể được thay đổi bằng các phương thức ghi đè trong lớp view_plugin_cache cục bộ, chẳng hạn như views_plugin_cache::get_cache_key().

8.0.0

Kể từ phiên bản 8.0.0-beta7 (lõi) vẫn giữ tùy chọn cho bộ đệm theo thời gian. Theo cách tốt nhất tôi có thể nói nó sẽ hoạt động như 7.x-3.x nhưng thực sự còn quá sớm để thực hiện bất kỳ thử nghiệm kết luận nào - hãy xem cuộc thảo luận meta này . Tuy nhiên, điều rõ ràng là nhiều mối quan tâm và hạn chế xung quanh bộ nhớ đệm dựa trên thời gian có thể trở thành tranh luận, vì có vẻ như các chế độ xem D8 cũng sẽ hỗ trợ bộ nhớ đệm dựa trên thẻ. Điều này sẽ cung cấp một cách để hết hạn thông minh dữ liệu được lưu trữ.