Cách tối ưu hóa trang WP cho hàng triệu bài đăng


19

Tôi đang làm việc trên một trang web cho một công ty rất có thể sẽ tạo ra hàng triệu bài đăng thông qua một loại bài đăng tùy chỉnh. Họ là những người cầu nguyện, vì vậy về cơ bản, người dùng ở mặt trước chỉ cần gửi một cụm từ ngắn thông qua một hình thức. Tất cả các công ty quan tâm là nội dung bài viết và ngày đăng. Trang web thậm chí chưa được ra mắt và họ đã có hơn 120.000 bài đăng, vì vậy tôi rất nghiêm túc khi tôi nói hàng triệu người.

Vì vậy, một vài câu hỏi tối ưu hóa:

  1. Giả sử tôi có một danh mục 'đặc trưng' trong loại bài đăng tùy chỉnh có 500.000 bài đăng. Các chuyên mục chỉ có 500 bài. Nếu tôi tạo một truy vấn cho các bài đăng nổi bật, tôi sẽ truy vấn toàn bộ 500.000 bài đăng, hay chỉ 500 bài nổi bật? Điều gì sẽ xảy ra nếu tôi chỉ muốn hiển thị mười bài đăng gần đây nhất được giới thiệu?
  2. Khi lưu loại bài đăng tùy chỉnh này vào cơ sở dữ liệu, tôi có thể làm gì để cắt giảm tài nguyên máy chủ, đặc biệt là vì điều duy nhất thực sự cần là nội dung của bài đăng và ngày?
  3. Tôi thậm chí có nên sử dụng một loại bài tùy chỉnh? Về nguyên tắc, tôi thích nó vì nó được tích hợp tốt vào quản trị viên WordPress, nhưng nếu có những bất lợi đáng kể về hiệu suất thì tôi cho rằng tôi có thể làm điều gì đó khác biệt.

Tôi chưa bao giờ làm việc trong một dự án ở quy mô này, vì vậy tôi quan tâm một chút đến hiệu suất hơn bình thường. Cảm ơn vì bất kì sự giúp đỡ!


Điều quan trọng là giữ các truy vấn cơ sở dữ liệu ở mức tối thiểu trong các chức năng WordPress của bạn và gọi các tập lệnh một cách thích hợp, nhưng một phần lớn của tối ưu hóa phải thực hiện với cách thiết lập và cấu hình máy chủ. Đối với điều đó, tìm kiếm mạng Server Fault. serverfault.com/search?q=optizes+wordpress
iyrin

@RyanLoremIpsum - cảm ơn vì nhận xét, nhưng tôi đã hy vọng trả lời cho câu hỏi cụ thể của mình. Hầu hết những gì tôi tìm thấy ở đó đều liên quan đến chính máy chủ, không phải cách WordPress vận hành và cách tối ưu hóa nó từ góc độ mã
Jeremiah Prummer

Câu trả lời:


25

1. Đặt truy vấn trước khi WP_Query chạy

Đây dường như là điều quan trọng nhất cần ghi nhớ khi cố gắng giữ các truy vấn cơ sở dữ liệu ở mức tối thiểu vì cơ hội duy nhất để thay đổi truy vấn là, tất nhiên, trước khi nó được chạy trong cơ sở dữ liệu SQL.

Truy vấn thông thường
Đối với một truy vấn bình thường, WordPress sử dụng wp()chức năng, lần lượt gọi $wp->main( $query_vars ). "Biến is_" từ các thẻ có điều kiện được đặt trước khi chuyển chúng sang WP_Query->get_posts(), nó chuyển đổi nó thành truy vấn cơ sở dữ liệu MySQL và cuối cùng lưu trữ chúng trong đối tượng $ wp_query. Có thể lọc truy vấn trước khi nó thực sự chạy trong cơ sở dữ liệu SQL .

Các pre_get_postshành động móc vào quá trình này, cho phép bạn thay đổi các truy vấn trước khi nó được chuyển cho WP_Query->get_posts().

Ví dụ: nếu bạn muốn lọc truy vấn cho các bài đăng trong danh mục "đặc trưng", bạn sẽ sử dụng add_action( 'pre_get_posts', 'your_function_name' );và bao gồm in_categorythẻ điều kiện bên trong your_function_name.

function your_function_name( $query ) {
    if ( $query->in_category( 'featured' ) && $query->is_main_query() ) {
        // Replace 123 with the category ID of the featured category.
        $query->set( 'cat', '123' );
    }
}
add_action( 'pre_get_posts', 'your_function_name' );

Xem API Plugin / Tham chiếu hành động / đăng bài trước «Codex WordPress

Yêu cầu trang
Đối với các mẫu trang, chẳng hạn như trang lưu trữ cho danh mục "đặc trưng", các thẻ có điều kiện sẽ không hoạt động từ pre_get_postsbộ lọc. Ví dụ: bạn không thể sử dụng is_categoryđể kiểm tra trang lưu trữ vì WP_Query chưa chạy.

Thay vào đó, bạn sẽ phải thay đổi truy vấn chính cho các yêu cầu trang với new WP_Querygiao diện giống như thế $query = new WP_Query( 'cat=123' );. Điều này chạy truy vấn với các đối số thích hợp được đặt từ đầu.

Xem Tham khảo lớp / Truy vấn WP «Codex WordPress

2. Lưu vào cơ sở dữ liệu

Bạn có thể sử dụng bộ lọc wp_insert_post_datađảm bảo rằng chỉ có dữ liệu $ có liên quan đến loại bài đăng tùy chỉnh của bạn được trả về wp_insert_post. Hãy chắc chắn bao gồm một tuyên bố có điều kiện để kiểm tra loại bài đăng tùy chỉnh của bạn.
Plugin API / Tham chiếu bộ lọc / wp chèn dữ liệu bài đăng «Codex WordPress

Móc này được gọi bởi wp_insert_posthàm, được gọi bởi wp_update_post khi bạn cập nhật loại bài đăng tùy chỉnh của mình, thường bằng cách lưu một bản nháp hoặc xuất bản bài đăng.

Bạn sẽ phải tự chuẩn hóa nó vì tôi không thể nói về ý nghĩa tối ưu hóa của việc giảm dữ liệu được cập nhật trong cơ sở dữ liệu.

3. Các loại bài tùy chỉnh có ảnh hưởng đến hiệu suất?

Theo kinh nghiệm của tôi, các loại bài đăng tùy chỉnh là một công cụ mạnh mẽ để quản lý nội dung. Tôi không biết cách nào khác để quản lý bài đăng theo tất cả các cách mà nó cho phép theo cách sử dụng ít tài nguyên hơn. Cá nhân tôi sẽ tập trung vào việc tìm cách giảm số lượng truy vấn được thực hiện bất cứ khi nào có thể.

Đã từng có một vấn đề về hiệu suất liên quan đến cấu trúc permalink khiến nó bị ảnh hưởng khi bắt đầu bằng văn bản thay vì số. 3 Điều này đặc biệt rắc rối đối với các trang web lưu trữ một số lượng lớn trang, nhưng đã được giải quyết kể từ phiên bản WordPress 3.3.

Tôi chỉ đưa ra permalinks ở đây vì sên thường là phần đầu tiên của cấu trúc permalink có thể có hoặc không ảnh hưởng đến hiệu suất trước phiên bản 3.3. Ngoài ra, tôi không biết về bất kỳ vấn đề hiệu suất nào phát sinh từ việc sử dụng các loại bài đăng tùy chỉnh.

Tùy chọn hiệu suất khác

Transents
Đây không phải là sự thay thế để giữ các truy vấn ở mức tối thiểu trong mã của bạn, nhưng bạn có thể sử dụng set_transient để lưu trữ các truy vấn trong một thời gian để các truy vấn mới không cần thiết. Dưới đây là ví dụ được sử dụng trong bài viết của Dave Clements . Ngoài ra, lưu ý rằng ông khuyên nên thêm một save_posthành động để xóa tạm thời bất cứ khi nào một loại bài đăng nhất định được cập nhật.

<?php // IN THE SPOTLIGHT QUERY
if( false === ( $its_query = get_transient( 'its_query' ) ) ) {
    $pttimestamp = time() + get_option('gmt_offset') * 60*60;
    $its_query = new WP_Query( array(
        'post_type' => 'spotlight',
        'posts_per_page' => 1,
            'post__not_in' => $do_not_duplicate,
        'meta_query' => array(
            array(
                'key' => '_hpc_spotlight_end_time',
                'value' => $pttimestamp,
                'compare' => '>'
            )
        )
    ) );
    set_transient( 'its_query', $its_query, 60*60*4 );
}
if( have_posts() ) { // HIDE SECTION IF NO CURRENT ITS FEATURE ?>
    // LOOP GOES HERE: NOT IMPORTANT TO EXAMPLE
<?php } ?>

Tối ưu hóa truy vấn nhiều hơn
Thomas Griffin có một vài mẹo hay trong hướng dẫn Tối ưu hóa Truy vấn WordPress của mình . Dưới đây là danh sách ngắn gọn những gợi ý của anh ấy:

  • Đặt 'cache_results' => falsetrong các truy vấn một lần nếu máy chủ của bạn không sử dụng bộ đệm ẩn liên tục như Memcached. Truy vấn một lần được mô tả là "truy vấn được sử dụng để hiển thị một lượng nhỏ dữ liệu. Có thể là bạn chỉ muốn hiển thị tiêu đề bài đăng được liên kết liên quan đến bài đăng hiện tại hoặc bạn có thể muốn hiển thị danh sách bài đăng thả xuống để chọn một thiết lập tùy chọn cụ thể. "

    Ví dụ của anh ấy: $query = get_posts( array( 'posts_per_page' => 1, 'cache_results' => false ) );

  • Đặt 'no_found_rows' => truenơi không cần phân trang. Điều này sẽ "bỏ qua MySQL đếm kết quả để xem chúng ta có cần phân trang hay không."

    Ví dụ của anh ấy: $query = new WP_Query( array( 'posts_per_page' => 1, 'no_found_rows' => true ) );

  • Truy vấn cho bài ID duy nhất nếu điều này là tất cả các bạn cần 'fields' => 'ids' trong get_posts. Điều này sẽ làm giảm đáng kể lượng dữ liệu được trả về, khá nhiều trên mỗi bài đăng nếu bạn xem Mô tả cơ sở dữ liệu «WordPress Codex

    Ví dụ của anh ấy: $query = get_posts( array( 'posts_per_page' => 1, 'fields' => 'ids' ) );

Ngoài mẹo cuối cùng đó, lý do tương tự có thể được áp dụng khi bạn chỉ cần một hoặc một vài trường đăng bài bằng cách sử dụng get_post_field .

Có một sự hiểu biết vững chắc về cách hoạt động của truy vấn là điều cần thiết. Bạn càng có thể cụ thể hơn với các truy vấn của mình, bạn sẽ càng yêu cầu ít công việc hơn từ cơ sở dữ liệu SQL của mình. Điều này có nghĩa là có rất nhiều khả năng để quản lý các truy vấn cơ sở dữ liệu. Hãy cẩn thận với các truy vấn tùy chỉnh ở nơi chúng chạy (có phải là trang quản trị không?), Sử dụng vệ sinh đúng cách trong các truy vấn trực tiếp và thử sử dụng các chức năng WordPress gốc nơi nó cho phép bạn đạt được hiệu suất tương tự.


2
Câu trả lời tuyệt vời và cực kỳ hữu ích, cảm ơn bạn!
Jeremiah Prummer

Chủ đề hoàn toàn được xây dựng tùy chỉnh, vì vậy chúng tôi chỉ thực sự truy vấn các mục hoàn toàn cần thiết. Đây là vô cùng hữu ích mặc dù. Vì điều này tôi sẽ quay lại và thực hiện một số thay đổi cho các truy vấn của mình. ;)
Jeremiah Prummer

1
Tôi muốn thêm rằng bạn nên tránh các truy vấn meta bất cứ khi nào có thể. Chắc chắn không chạy một truy vấn đối với hai trường meta cùng một lúc. Điều này dẫn đến các truy vấn kép và ba nhanh chóng trở thành một vấn đề khó khăn về hiệu suất. Các loại bài tùy chỉnh thường có thể giúp với điều này.
Charles Jaimet

3

Tôi cũng thêm:

    'no_found_rows'          => true,
    'update_post_term_cache' => false,
    'update_post_meta_cache' => false,
    'cache_results'          => false
  • no_found_rows (boolean) - biến nó thành sự thật khi bạn không cần bất kỳ phân trang nào và không cần tổng số bài đăng được tìm thấy.
  • cache_results (boolean) - Đăng thông tin bộ đệm.
  • update_post_meta_cache (boolean) - Đăng bộ đệm thông tin meta.
  • update_post_term_cache (boolean) - Đăng bộ nhớ cache thông tin thuật ngữ.

Bằng cách sử dụng các tham số này và truyền các giá trị dưới dạng FALSE, chúng ta có thể thực hiện truy vấn nhanh hơn bằng cách dừng một số truy vấn cơ sở dữ liệu bổ sung đang được thực thi.

Lưu ý: Chúng ta không nên sử dụng các tham số này luôn vì việc thêm mọi thứ vào bộ đệm là điều nên làm, tuy nhiên chúng có thể hữu ích trong các trường hợp cụ thể và bạn nên cân nhắc sử dụng khi bạn biết bạn đang làm gì.

Vui lòng truy cập: https://drujoopress.wordpress.com/2013/06/27/how-to-optizes-wordpress-query-to-get-results-faster/#more-184


1
Vui lòng chỉnh sửa câu trả lời của bạn và thêm một lời giải thích: tại sao điều đó có thể giải quyết vấn đề?
fuxia

Tôi không thể thêm nhận xét của mình vào câu trả lời này: wordpress.stackexchange.com/a/166699/57674
Rigosan

1

Vì tất cả các loại câu hỏi tối ưu hóa sớm, câu hỏi này thực sự không thể được trả lời mà không biết chính xác các kiểu sử dụng mà quá nhiều lần chỉ được phát hiện khi bạn phát trực tiếp.

Nói chung, mỗi thông số kỹ thuật MYSQL không nên có bất kỳ vấn đề nào với lượng dữ liệu. Tất nhiên việc tìm kiếm dữ liệu ngay cả với các thuật toán tốt nhất sẽ chậm hơn với các bảng nhỏ hơn nhiều nhưng giải pháp cho điều đó là CPU đơn giản, mạnh hơn.

Bạn có thể muốn tối ưu hóa cách lưu trữ dữ liệu meta (ví dụ: không lưu trữ dữ liệu liên quan đến ping), nhưng điều này phụ thuộc vào chính xác những gì bạn làm và cuối cùng bạn vẫn có thể cần CPU mạnh hơn nên có thể không đáng để bạn gặp rắc rối .

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.