Google XML Sitemap là một trong những plugin không thể thiếu của tôi, trước đây khi plugin này chưa hỗ trợ Multisite, tôi đã không sử dụng nó, nhưng rồi tới khi nó hỗ trợ, tôi lại không sử dụng tính năng cho Multisite của nó :D, đúng là ngịch lý của cuộc sống.

Về cơ bản, chức năng của nó không thay đổi nhiều, có một cải tiến lớn đó là việc hỗ trợ Nginx, với cấu hình sau, đây là những gì bạn cần cấu hình thêm khi chạy WordPress cùng Nginx

rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml$ "/index.php?xml_sitemap=params=$2" last;
rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml\.gz$ "/index.php?xml_sitemap=params=$2;zip=true" last;
rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html$ "/index.php?xml_sitemap=params=$2;html=true" last;
rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html.gz$ "/index.php?xml_sitemap=params=$2;html=true;zip=true" last;

Việc cấu hình trên, mục đích để  Rewrite đường dẫn sao cho thật dễ nhớ, không có thì cũng không sao cả, bạn sẽ có một link sitemap với vô số các tham biến ở sau. Tôi sử dụng cho việc không phải nhớ mỗi khi submit website lên Google Webmaster Tool, hay Bing.

Quay về nội dung chính, một plugin tốt như vậy, có hơn 1 triệu lượt download tại sao lại có vấn đề. Trở ngại nằm ở chỗ, khi xây dựng plugin, tác giả chưa tính tới việc dữ liệu sẽ dày lên trong tương lai, vốn là người mong muốn trải nghiệm với hệ thống lớn, tôi luôn sẵn sàng để kiểm tra đâu là plugin tốt, và đối với tôi, đó phải là plugin thiết kế tốt cho tương lai của dữ liệu khổng lồ.

Hai điểm quan trọng Plugin này mắc phải đó là sử dụng truy vấn SQL không tuân thủ nguyên tắc đơn giản.

//Statement to query the actual posts for this post type
      $qs = "
        SELECT
          p.ID,
          p.post_author,
          p.post_status,
          p.post_name,
          p.post_parent,
          p.post_type,
          p.post_date,
          p.post_date_gmt,
          p.post_modified,
          p.post_modified_gmt,
          p.comment_count
        FROM
          {$wpdb->posts} p
        WHERE
          p.post_password = ''
          AND p.post_type = '%s'
          AND p.post_status = 'publish'
          AND YEAR(p.post_date_gmt) = %d
          AND MONTH(p.post_date_gmt) = %d
          {$exPostSQL}
          {$exCatSQL}
        ORDER BY
          p.post_date_gmt DESC
      ";

Bạn thấy đấy, trong truy vấn WHERE tác giả sử dụng hàm YEAR và MONTH để so sánh, mục đích truy vấn này để lọc ra các bài viết có trong cùng một tháng. Tất nhiên bạn có thể thay đổi như sau để có thể giúp hệ thống chạy nhanh hơn, đừng quên comment lại các dòng trên nhé.

// @dungnq optimize start
                        if ($month == 12) {
                            $next_year = $year+1;
                            $next_month = '01';
                        }
                        else {
                            $next_year = $year;
                            $next_month = $month+1;
                        }
                        
                        $qs = "
        SELECT
          p.ID,
          p.post_author,
          p.post_status,
          p.post_name,
          p.post_parent,
          p.post_type,
          p.post_date,
          p.post_date_gmt,
          p.post_modified,
          p.post_modified_gmt,
          p.comment_count
        FROM
          {$wpdb->posts} p
        WHERE
          p.post_password = ''
          AND p.post_type = '%s'
          AND p.post_status = 'publish'
          AND p.post_date_gmt >= '{$year}-{$month}-01 00:00:00'
                                        AND p.post_date_gmt 
Thay đổi ở trên của tôi rất đơn giản, hay vi sử dụng hàm trong câu lệnh điều kiện WHERE tôi xác định luôn một khoảng thời gian nhất định từ là ngày phát hành bài viết phải từ 0 giờ này 1 của tháng, tới trước 0 giờ ngày 1 của tháng kế tiếp, những dòng trên đầu của tôi sử dụng để lấy ra tháng hiện tại và tháng kế tiếp, đặc biệt với tháng 12 thì cần nhảy lên 1 năm.

Còn một điểm lưu ý nữa, nhưng trong tôi nghĩ sẽ chia sẻ cùng các bạn trong tuần tới, nhừng quên ghé tham blog của tôi hàng tuần để nhận được những thông tin  về cách tối ưu WordPress với lượng dữ liệu khổng lồ nhé.

 

Nếu bạn là một blogger sử dụng WordPress như một công cụ đề xuất bản những bài viết của mình, thì nội dung này sẽ không hề hợp với bạn. Ở đây tôi đóng vai trò là một người quản trị, sử dụng wordpress cho những hệ thống lớn, có nhiều người truy cập, cũng như số lượng bài viết mỗi ngày được phát hành là không hề nhỏ?

Vấn đề là gì, như những gì bạn có thể đã biết, WordPress cho  một cơ chế ping tới các search engine, nghĩa là sau khi bạn phát hành bài viết, bằng cách này hay cách khác, WordPress sẽ tự động đẩy những nội dung tới các cỗ máy tìm kiếm để thông báo bài viết của bạn tồn tại, hoặc đã được chỉnh sửa.

Thảm họa xảy ra là gì? Nếu 1 ngày bạn chỉ có từ 1 – 2 bài viết, thì không nói, nhưng với một hệ thống lớn, số lượng có thể lên đến 100, 200, thậm chí là 1000 bài viết cần xuất bản mỗi ngày. Tới đây chính là giới hạn của WordPress, hãy thử tưởng tượng, trong một lần xử lý, hệ thống sẽ ping tới Search Engine từ 100 đến 1000 lần, tất nhiên còn phụ thuộc vào tốc độ kết nối, khả năng xử lý của CPU… nhưng cái mà tôi đề cập tới chính là tài nguyên bị giữ lại cho việc xử lý này mới thực là vấn đề, PHP không phải là ngôn ngũ viết tối ưu cho bộ nhớ trong RAM, nên chạy càng lâu, vòng lặp càng lớn thì hệ thống bạn sớm bị cạn kiệt. Hệ quả là, server còi của bạn không còn đủ tài nguyên để phục vụ khách hàng truy cập nữa.

Điều bạn nên làm là gì, hay tìm  đoan code sau trong thư mục wp-include/comment.php, tìm kiếm hàm do_all_pings và thay đổi theo mẫu dưới đây của tôi gợi ý.

/**
 * Perform all pingbacks, enclosures, trackbacks, and send to pingback services.
 *
 * @since 2.1.0
 *
 * @global wpdb $wpdb WordPress database abstraction object.
 */
function do_all_pings() {
  global $wpdb;
  
    $limit = get_option('posts_per_page', 10); // @dungnq get limit of post per page
  // Do pingbacks
  $count=0; // @dungnq count
  while ($ping = $wpdb->get_row("SELECT ID, post_content, meta_id FROM {$wpdb->posts}, {$wpdb->postmeta} WHERE {$wpdb->posts}.ID = {$wpdb->postmeta}.post_id AND {$wpdb->postmeta}.meta_key = '_pingme' LIMIT 1")) {
    delete_metadata_by_mid( 'post', $ping->meta_id );
    pingback( $ping->post_content, $ping->ID );
    $count++; //@dungnq
    if ($count >= $limit) break; // @dungnq
  }

  // Do Enclosures
  $count=0; // @dungnq count
  while ($enclosure = $wpdb->get_row("SELECT ID, post_content, meta_id FROM {$wpdb->posts}, {$wpdb->postmeta} WHERE {$wpdb->posts}.ID = {$wpdb->postmeta}.post_id AND {$wpdb->postmeta}.meta_key = '_encloseme' LIMIT 1")) {
    delete_metadata_by_mid( 'post', $enclosure->meta_id );
    do_enclose( $enclosure->post_content, $enclosure->ID );
    $count++; //@dungnq
    if ($count >= $limit) break; // @dungnq
  }

  // Do Trackbacks
  //$trackbacks = $wpdb->get_col("SELECT ID FROM $wpdb->posts WHERE to_ping  '' AND post_status = 'publish'");
  $trackbacks = $wpdb->get_col("SELECT ID FROM $wpdb->posts WHERE to_ping  '' AND post_status = 'publish' LIMIT $limit");
  if ( is_array($trackbacks) )
    foreach ( $trackbacks as $trackback )
      do_trackbacks($trackback);

  //Do Update Services/Generic Pings
  generic_ping();
}

Thay vì sử dụng vòng lặp vô tận cho tới khi hết các post mới nhất cần ping, tôi chỉnh lại một chút thôi, lấy số giới hạn là số lượng post hiển thị trên trang chủ hoặc feed, sau đó sử dụng bộ đếm để thoát khỏi vòng lặp while.

Tôi đã hoàn toàn giữ lại code của WordPress để bạn tham khảo? Nếu bạn vẫn có suy nghĩ là WordPress chỉ là nền tảng của các blogger, hay tham khảo tờ The Sun nổi tiếng của UK, các kỹ sư đã biết wordpress trở thành một nền tảng cho báo chí vô cùng linh hoạt. Còn sức mạnh của nó đến đâu, tùy bạn kiểm chứng, tôi chỉ có thể chia sẻ rằng, nó nằm trong chính khối óc của bạn, hãy tận dụng thành quả 10+ năm tuyệt vời của những con người xây dựng nên WordPress, đừng biến mình trở thành những nhà khoa học đi phát minh lại những bánh xe.