Blog WordPress với 30 000 bài viết: hiệu suất tìm kiếm kém

Blog WordPress của chúng tôi đã chạy tốt cho đến khi chúng tôi nhập khoảng 30k bài đăng. Việc tìm kiếm trên trang web trở nên rất chậm sau đó.

Bây giờ mất khoảng:
- 4 giây để tải một trang với tiện ích Tìm kiếm & Bộ lọc trên đó.
- 18 giây để trả về kết quả tìm kiếm.

Các plugin chính mà chúng tôi sử dụng:
Loại bài đăng tùy chỉnh - chúng tôi chỉ có một loại bài đăng tùy chỉnh được sử dụng trong blog.
Các trường tùy chỉnh nâng cao - chúng tôi có một bộ các trường tùy chỉnh có thể tìm kiếm và lọc được.

Các plugin tìm kiếm mà chúng tôi sử dụng:
Tìm kiếm mọi thứ - chúng tôi đã bật Thẻ, Tác giả và Nhận xét để tìm kiếm. Nội dung bài đăng, tiêu đề và các trường tùy chỉnh có thể tìm kiếm theo mặc định.
Search & Filter Pro - được sử dụng để xây dựng tiện ích tìm kiếm và bộ lọc của chúng tôi và đặt quy tắc lọc.

Bộ nhớ đệm:
Chúng tôi đang sử dụng Memcache làm bộ đệm có thể cắm cho WP cũng như giải pháp bộ đệm liên tục.

Môi trường:
Máy chủ vật lý: AWS t2.small; Bộ nhớ 2 GB; CPU 1 lõi lên đến 3,3 GHz
Hệ điều hành: Máy chủ web Windows Server 2012
: IIS 8.5
PHP 5.6.22
Wordpress 4.6.1 MySQL 5.6.27 (ví dụ RDS chuyên dụng)

Chúng tôi có một cơ sở người dùng khá hạn chế và không quan sát thấy các đột biến đáng kể trong việc sử dụng tài nguyên máy chủ cho cả máy chủ ứng dụng và máy chủ db.

Đây là truy vấn SQL chạy dài nhất được thực thi khi người dùng thực hiện tìm kiếm trên trang web:

SELECT SQL_CALC_FOUND_ROWS distinct wp_posts.ID
FROM   wp_posts
       LEFT JOIN wp_postmeta
              ON wp_posts.id = wp_postmeta.post_id
       LEFT JOIN wp_term_relationships AS trel
              ON ( wp_posts.id = trel.object_id )
       LEFT JOIN wp_term_taxonomy AS ttax
              ON ( ( ttax.taxonomy = 'post_tag' )
                   AND trel.term_taxonomy_id = ttax.term_taxonomy_id )
       LEFT JOIN wp_terms AS tter
              ON ( ttax.term_id = tter.term_id )
       LEFT JOIN wp_comments AS cmt
              ON ( cmt.comment_post_id = wp_posts.id )
       LEFT JOIN wp_users AS u
              ON ( wp_posts.post_author = u.id )
WHERE  1 = 1
       AND ( ( wp_posts.id IN (<LIST_OF_POST_IDS>)
               AND (( (( ( wp_posts.post_title LIKE '%searchterm%' )
                          OR ( wp_postmeta.meta_value LIKE '%searchterm%' )
                          OR ( wp_posts.post_content LIKE '%searchterm%' ) ))
                       OR (( tter.name LIKE '%searchterm%' ))
                       OR ( (( cmt.comment_content LIKE '%searchterm%' ))
                            AND cmt.comment_approved = '1' )
                       OR (( u.display_name LIKE '%searchterm%' )) ))
               AND wp_posts.post_type = 'generalpost'
               AND (( wp_posts.post_status = 'publish' )) )
             AND post_type != 'revision' )
       AND post_status != 'future'
ORDER  BY wp_posts.post_date DESC
LIMIT  0, 15;

Vui lòng xem tài liệu DB Wordpress để tham khảo lược đồ

Truy vấn này chịu trách nhiệm cho khoảng 65% thời gian tải trang kết quả tìm kiếm (12 giây trong số 18 giây)

Chúng tôi chỉ có 1 loại bài đăng tùy chỉnh tại thời điểm này và chỉ có thể tìm kiếm được. Mỗi loại bài đăng tùy chỉnh có 18 bản ghi trong wp_postmeta. Trong số 18 trường đó, chỉ có 4 trường cần tìm kiếm - và đó là một cách tiềm năng để tăng tốc tìm kiếm.

Trong các thử nghiệm của tôi thêm điều khoản này

`AND meta_key in ('cust_field1', 'cust_field2', 'cust_field3', 'cust_field4',)`

thực sự tăng tốc truy vấn gần hai lần. Các nhà phát triển plugin đã được liên hệ để triển khai một tính năng để hỗ trợ loại trừ trường meta.

Tôi cũng đã tạo một chỉ mục ghép trên các cột post_id, meta_key, meta_value , giúp cắt giảm thời gian truy vấn thêm 5-10%.

Điều gì sẽ là những cách khác để làm cho tìm kiếm với lượng dữ liệu này hiệu quả hơn để trải nghiệm người dùng không bị hủy hoại?

Có vẻ như bạn đã đi đúng hướng, thêm các chỉ mục bổ sung và điều chỉnh truy vấn. Tôi đã thấy cú pháp của MySQL EXPLAINlà hữu ích , mang lại cho tôi cảm giác tốt về nơi mà trong truy vấn mọi thứ có thể trở nên tồi tệ.

Từ cấp độ cao, có vẻ như truy vấn có rất nhiều bảng được LIKEso sánh , so sánh (với ký tự đại diện) và bộ ORso sánh, tất cả đều có triệu chứng của các truy vấn có khả năng ít hiệu quả hơn. Tôi đảm bảo rằng mỗi cột trong số đó được lập chỉ mục chính xác (đặc biệt là các cột có lẽ thường không được truy vấn) và xem bạn có bỏ sót điều gì ở đó không.

Kích thước cơ sở dữ liệu tổng thể có thể là một yếu tố trong một số môi trường; Tại một thời điểm, một trang web của khách hàng đã phàn nàn về hiệu suất chậm (không chỉ tìm kiếm) và chúng tôi đã phát hiện ra rằng các chỉ mục bị nghẹt thở vì thực tế là khoảng 20% ​​cơ sở dữ liệu được tạo thành từ các sửa đổi bài đăng (đây là một trang web tin tức hàng ngày, vì vậy sửa đổi trên một bài đăng từ sáu tháng trước không thực sự phù hợp). Revision Strike ra đời từ nhu cầu đó và có tác động rất lớn đến hiệu suất chung - cũng như tìm kiếm - trang web.

Một lựa chọn khác để xem xét là một cái gì đó dựa trên một công nghệ tìm kiếm chuyên dụng hơn. ElasticPress (công bố đầy đủ: Tôi làm việc trong 10up, người duy trì đàn hồi) liên kết Elaticsearch vào các truy vấn WordPress, giảm đáng kể tải trên máy chủ web của bạn trong khi có thể thực hiện các tìm kiếm phức tạp hơn (như bạn dường như đang thực hiện với các plugin tìm kiếm của mình) .