Bộ đệm đối tượng ở mọi nơi
WordPress cố gắng giảm số lượng truy vấn cơ sở dữ liệu càng nhiều càng tốt.
Ví dụ: bất cứ khi nào bạn nhận được một trường meta hoặc trường phân loại, trước khi truy vấn cơ sở dữ liệu, WordPress sẽ xem xét nếu đó đã được truy vấn và lưu trữ trong bộ đệm và trả về từ đó thay vì truy vấn cơ sở dữ liệu.
"Công việc bộ đệm" được thực hiện thông qua WP_Object_Cache
lớp và các wp_cache_*
hàm (đó là trình bao bọc cho các phương thức lớp đó.)
Bộ nhớ cache sống ở đâu
Theo mặc định, "bộ đệm" không có gì khác hơn là một biến toàn cục PHP. Nó có nghĩa là nó nằm trong bộ nhớ, nhưng cũng có nghĩa là nó biến mất trong mọi yêu cầu.
Tuy nhiên, thông qua dropins ( advanced-cache.php
và / hoặc object-cache.php
), có thể thiết lập một cách tùy chỉnh để xử lý bộ đệm này.
Thông thường, các dropins này được sử dụng để thiết lập một số loại cơ chế lưu trữ "tồn tại" các yêu cầu số ít.
Vì lý do này, trong số những người WP, chúng được gọi là các plugin "bộ đệm liên tục" (ngay cả khi bên ngoài bong bóng, các từ "bộ đệm" và "liên tục" không có nhiều ý nghĩa với nhau).
Các lựa chọn phổ biến hiện nay là Memcached hoặc Redis .
Vì vậy, bằng cách sử dụng các plugin "bộ đệm liên tục", bạn có thể giảm đáng kể số lượng truy vấn cơ sở dữ liệu, vì bộ đệm không được cập nhật theo mỗi yêu cầu.
Vài ví dụ
$foo = get_post_meta('foo', $post_id, true);
// a lot of code in the middle
$bar = get_post_meta('bar', $post_id, true);
2 dòng mã ở trên sẽ kích hoạt, tối đa, 1 truy vấn cơ sở dữ liệu.
Trong thực tế, khi bạn truy vấn một trường tùy chỉnh, tất cả các trường cho bài đăng đó được truy xuất từ cơ sở dữ liệu, được lưu trữ qua bộ đệm đối tượng và các yêu cầu tiếp theo lấy dữ liệu từ bộ đệm chứ không phải từ db.
Điều tương tự cũng xảy ra đối với các thuật ngữ phân loại, WordPress rút tất cả các thuật ngữ cho phân loại một lần, sau đó trả lại chúng từ bộ đệm.
Bộ đệm đối tượng được sử dụng rất rộng rãi trong WordPress. Không chỉ cho các bài đăng, giá trị meta và phân loại, mà còn cho người dùng, nhận xét, dữ liệu chủ đề ...
Những gì WP_Query
phải làm với tất cả những điều này?
Khi bạn truy vấn một số bài đăng qua WP_Query
, theo mặc định, WordPress không chỉ lấy chúng từ cơ sở dữ liệu (hoặc từ bộ đệm nếu chúng được lưu trong bộ nhớ cache) mà còn cập nhật bộ đệm cho tất cả các trường tùy chỉnh và tất cả các phân loại liên quan đến bài đăng được kéo.
Vì vậy, khi bạn gọi, ví dụ, get_the_terms()
hoặc get_post_meta()
trong khi các bài đăng lặp đi lặp lại WP_Query
, bạn thực sự không kích hoạt bất kỳ truy vấn cơ sở dữ liệu nào, nhưng lấy thông tin từ bộ đệm.
Đẹp phải không?
Vâng, có, nhưng nó đi kèm với một chi phí.
Bản cập nhật bộ đệm "ma thuật" mà WordPress thực hiện khi kéo bài đăng qua WP_Query
xảy ra trong update_meta_cache
meta và trong update_object_term_cache
phân loại.
Nếu bạn nhìn vào mã nguồn của các hàm đó, bạn sẽ thấy rằng WordPress chỉ thực hiện một truy vấn db trong mỗi hàm, nhưng cũng xử lý rất nhiều. Ví dụ: trong update_object_term_cache
đó có 7 lồng nhauforeach
... nếu bạn có nhiều phân loại và số lượng bài đăng trên mỗi trang cao, điều này không hiệu quả lắm.
Về những WP_Query
tranh luận đó, cuối cùng
Những gì 'update_post_meta_cache'
và 'update_post_term_cache'
làm khi được đặt false
là ngăn WordPress cập nhật bộ đệm cho các trường tùy chỉnh và phân loại tương ứng.
Trong trường hợp đó, lần đầu tiên một trường tùy chỉnh hoặc phân loại được truy vấn, một truy vấn cơ sở dữ liệu được kích hoạt và dữ liệu được lưu trữ.
Nó có đáng để gặp rắc rối?
Như thường lệ, câu trả lời là tùy thuộc . Hầu hết thời gian để đặt các giá trị đó thành false
, là một lựa chọn tốt, bởi vì nó ngăn chặn các truy vấn cơ sở dữ liệu và xử lý không cần thiết nếu không cần thiết và bộ đệm được cập nhật dù sao là điều khoản trường / phân loại tùy chỉnh lần đầu tiên được yêu cầu.
Tuy nhiên, nếu bạn định gọi, dù chỉ một lần, get_post_meta()
trong vòng lặp và bạn sẽ gọi get_the_terms()
cho tất cả (hoặc hầu hết) các phân loại được hỗ trợ bởi các bài đăng, thì cập nhật bộ đệm được kích hoạt bằng mọi cách và có thể không có lợi ích thực sự nào trên thiết lập các đối số truy vấn thành false
.
wp_reset_postdata()
là để đặt lạiglobal $post
và đặt lại Bộ đệm đối tượng? Có vẻ như nếu tôi đã thực hiện một WP_Query tùy chỉnh, nó sẽ tạo một đối tượng được lưu trong bộ nhớ cache mới nhưng việc đặt lại nó cũng sẽ phải yêu cầu để có được bộ đệm ban đầu. Hoặc có lẽ tôi đang đi quá xa trong bối cảnh của câu hỏi này.