Đừng bắt chước nhân tài “1000 năm có 1” như Mark Zuckerberg hay Jeff Bezos: Thành công nằm ở 6 điều các “triệu phú nhà bên” đang làm cạnh bạn!

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.

Nếu bạn đã sử dụng wordpress vì bất kỳ một lý do nào đó, bạn đã vô tình sử dụng rất nhiều tiện ích kèm theo của CMS mã mở, mà đối với tôi là tốt nhất trên thế giới hiện nay.

Vơi hệ thống Backend rất thân thiện, tiêu chí đầu tiên của tôi so sánh khi lựa chọn mình nên theo con đường nào Joomla, Zend Framework, hay WordPress. Quả thật là tôi không hề sai lầm khi khám phá cả một cộng đồng lớn với yêu ý tưởng thú vị. Quan trọng hơn, tôi không cần phải mất 6 tháng 1 năm để thử một ý tưởng điên rồ của mình.

Nếu là tay ngang, bạn cũng được thừa hưởng rất nhiều nhưng tính năng ưu việt, mà không có CMS tự phát triển nào có được, khi bạn viết một bài trên hệ thống của mình, WordPress sẽ tự động thông báo với các Search Engine là nội dung của bạn đã tồn tại qua hệ thống ping do chính WordPress phát triển. Tất nhiên bạn sẽ may mắn hơn một cơ số những người ngồi ngoài kia, sử dụng những biện pháp thông thường.

Tuy nhiên, hôm nay tôi cũng muốn giới thiệu cho các bạn một plugin khá thu vị, bổ sung vào những gì chúng ta còn thiếu, đó là Google XML Sitemap, bạn có thể download trực tiếp ở địa chỉ sau

https://wordpress.org/plugins/google-sitemap-generator/

Ping tới Search Engine thôi chưa đủ, cách tốt nhất bạn cần đó là cho Search Engine biết tường tận ngóc ngách ngôi nhà trên internet của bạn, đây là plugin miễn phí mà tôi thấy đáng giá nhất. Những phiên bản trước đây của plugin vốn không hỗ trợ Multisite, tuy nhiên ở phiên bản mới nhất việc này đã được hỗ trợ tối đa.  Plugin này đã ra đời được 9 năm, và hiện nay có trong top những plugin được đánh giá cao nhất.

Tuy nhiên bạn đang ở blog của tôi, nơi bạn có thể tìm thấy các vấn đề khác ngoài việc giới thiệu các tính năng của plugin, tôi sẽ gửi tới các bạn một số vấn đề khác của plugin khi sử dụng với hệ thống có dữ liệu đồ sộ ở những bài sau nhé.

Còn bây giờ, nếu bạn chưa từng sử dụng plugin này, hay khám phá và giúp blog của mình tiến gần hơn với Search Engine nhé.

Nếu dữ liệu của bạn đủ lớn, khoảng tầm 500 ngàn đến 1 triệu bản ghi, bạn sẽ thấy hậu quả nhanh chóng từ việc sử dụng hàm này. Việc tiện dụng là không thể phủ nhận, nhưng khi sử dụng hàm trên, sẽ dẫn đến việc so sánh để tìm ra bài viết có post_title phù hợp.

Tuy nhiên, nếu bạn để ý, WordPress sử dụng post_title là text, việc truy vấn dữ liệu text, không hề được index là một thảm hoạ vô cùng lớn. Như trường hợp của tôi, cần so sánh post được gửi thông qua xmlrpc xem đã từng tồn tại trên hệ thống chưa. Rất may, lệnh truy vấn này không thực sự nhiều, và chưa quá ảnh hưởng nghiêm trọng tới hệ thống của tôi.

Tuy nhiên sau khi loại bỏ những dòng lệnh trên, hệ thống trở về điều kiện hoàn toàn bình thường, CPU giảm hẳn đi 1/2, I/O giảm rõ rệt. Vì một phút nhanh chóng làm cho xong plugin của mình theo guilde online, tôi đã phải trả giá cho hiệu năng hệ thống của mình.