Categories Cache Litespeed

Hướng dẫn cài đặt plugin LiteSpeed Cache (p3)

hướng dẫn sử dụng LiteSpeed phần 3

Chú thích của người dịch: phần này là phần cuối trong chuỗi bài viết hướng dẫn cách dùng LiteSpeed Cache. Bạn có thể tham khảo phần 1phần 2 ở đây.

Database > Manage

Phần này gồm các công cụ tối ưu hóa và làm sạch cơ sở dữ liệu có chất lượng rất tốt (incredible). Một số thậm chí có thể tách riêng ra đem bán được. Có vài ý kiến đóng góp của tôi đã được LiteSpeed ghi nhận triển khai. <3

  • Clean All (làm sạch tất cả) – thực hiện tất cả công việc tối ưu hóa trong danh sách.
  • Post Revisions – xóa tất cả post revisions.
  • Auto Drafts – bạn cần kiểm tra trước khi xóa các bản nháp này.
  • Trashed Posts – bạn cần kiểm tra trước khi xóa các bài trong thùng rác.
  • Spam Comments – xóa các bình luận spam, đôi khi bình luận thông thường cũng bị đưa vào đây, nếu cẩn thận thì bạn nên kiểm tra trước khi xóa.
  • Trashed Comments (bình luận trong thùng rác) – cái tên đã nói lên tất cả (self-explanatory).
  • Trackbacks/Pingbacks – xóa được.
  • Expired Transients – đủ an toàn để xóa .
  • Optimize Tables (tối ưu hóa bảng) – không cần lăn tăn.
  • Clean CSS/JS Optimizer – không cần lăn tăn.
  • Database Table Engine Converter > Convert to InnoDB – ổn cả, bạn nên làm điều này cho tất cả các bảng! InnoDB là định dạng bảng MySQL tốt hơn so với dạng cũ MyISAM.
  • Database Summary (tổng quan về cơ sở dữ liệu) – tôi rất thích xem thông tin những gì đang tự động tải trên trang của tôi. Bạn nên giữ tổng dung lượng tự động tải dưới 1MB, tốt nhất là dưới 500KB.

Database > DB Optimization Settings

  • Revisions Max Number (số lượng revisons tối đa) – thiết lập giới hạn nếu database của bạn quá lớn và bạn có nhiều bài post. Cá nhân tôi để nó là 0 để trang web được gọn gàng, sạch sẽ. Nhưng các trang khác thận trọng hơn có thể để từ 10 đến 50.
  • Revisions Max Age (tuổi tối đa của revision) – bạn có thể thiết lập để nó tự động xóa các revision sau một khoảng thời gian nhất định. Cá nhân tôi nghĩ điều này thật đáng sợ khi bài post của bạn gặp vấn đề và bạn không để ý đến nó suốt một thời gian dài.

Crawler > Summary

PS1: Ngoài phần hướng dẫn bên dưới của Johnny Nguyen, bạn có thể đọc tài liệu về Crawler từ chính chủ LiteSpeed, link ở đây.

PS2: Thiết lập phần này khéo léo giúp trang web của bạn có tỷ lệ trang được cache cao (tức là trang khi người dùng truy cập vào đã được cache).

Phần này sẽ không có nhiều hiệu quả trừ khi bạn có máy chủ của riêng mình, phần lớn công ty host cài LiteSpeed không cho phép tùy chọn crawler (vì nó có thể chiếm dụng một lượng lớn tài nguyên). Bạn không cần phải mó máy (mess) bất cứ điều gì ở đây trừ khi bạn muốn crawler tạo trước cache (precache) tích cực hơn. Và bây giờ, có rất nhiều tùy chọn tích cực! Bạn có thể tăng tần số crawl (quét, thu thập dữ liệu) hoặc thread-use, thậm chí là precrawl cho các cookies và người dùng đã đăng nhập, vân vân.

PS: cá nhân người dịch từng dùng host ở Closte, có chất lượng rất ổn, nhưng họ cũng không bật tính năng này:

vô hiệu hóa crawler

Nếu bạn tự cài LiteSpeed/OpenLiteSpeed chẳng hạn trên DigitalOcean hoặc Vultr, tính năng này sẽ được mở theo mặc định.

  • Summary > Reset position – reset nó nếu bạn muốn bắt đầu lại từ đầu, giống như sau khi bạn xóa cache.
  • Summary > Manually run – khởi động lại thủ công crawler thay vì đợi cho đến khi cron job kế tiếp chạy.
  • Map > Clean Crawler Map – một crawler map giống như một sitemap cho crawler (trình thu thập dữ liệu) của bạn. Bạn có thể xóa nó bất cứ khi nào bạn muốn để tạo ra cái mới (chẳng hạn sau khi các trang mới được thêm vào).
  • Map > Refresh Crawler Map – có thể là ý tưởng hay khi refresh lại cái này sau khi trang thay đổi hoặc sau khi bạn reset “cleaned” crawler map. Sau đó bạn có thể xem các trang nào đã được crawled hoặc không, cũng như thêm vào blacklist để ngăn các trang không được tự động crawl.
  • Blacklist > Empty blacklist – xóa sạch blacklist của bạn nếu cần thiết.

Crawler > General Settings

  • Crawler – bật nó nếu bạn muốn xây dựng cache tự động. Cái này cần sử dụng tài nguyên vì thế có thể không phải là ý hay nếu bạn dùng trên máy chủ bận rộn mà nhiều website không phải của bạn (làm ảnh hưởng đến người khác). Tất nhiên, nếu đó là máy chủ của bạn và chạy các website của bạn thì bạn nên bật nó để sử dụng nhiều tài nguyên nhất có thể!
  • Delay – mặc định là ổn rồi. Cái này chỉ cần điều chỉnh nếu bạn có trên 30 ngàn trang trên toàn máy chủ!
  • Run Duration – giá trị mặc định cũng ổn nhưng bạn có thể tăng nó lên cho các trang quan trọng.
  • Interval Between Runs – giá trị mặc định cũng ổn nhưng bạn có thể giảm nó cho các trang quan trọng hoặc/và máy chủ rảnh rỗi.
  • Crawl Interval – giá trị khuyến nghị là 302400 (3,5 ngày) hoàn toàn ổn nhưng bạn có thể tăng nó lên thành 86400 (1 ngày) nếu trang web của bạn không quá lớn (dưới 3K trang) hoặc bạn đang dùng máy chủ riêng.
  • Threads – giá trị mặc định 3 là ổn. Thiết lập giá trị crawl cao hơn sẽ nhanh hơn nhưng để như mặc định cũng không thành vấn đề trừ khi bạn có ít nhất vài trăm page. Nó cũng sử dụng nhiều CPU hơn vì thế đừng thiết lập chỉ số này cao quá nếu bạn có máy chủ bận rộn với nhiều website.
  • Server IP – chức năng thực sự thú vị giúp giảm công sức crawl. Thực sự hữu ích nếu bạn có trên 1K trang.
  • Server Load Limit – giá trị khuyến nghị 1 là giới hạn an toàn tốt. Nhưng tôi thích để nó là 2 hoặc 3 nếu bạn đang có máy chủ riêng (ý là không phải sharehost).

Crawler > Simulation Settings

Phần này chỉ cần nếu bạn muốn crawl trước các trang cho người dùng đã đăng nhập (chức năng crawl thông thường đã bao gồm người dùng không đăng nhập).

  • Role Simulation – tạo cache trước cho các trang ứng với người dùng cụ thể.
  • Cookie Simulation – crawl trước cho các cookies cụ thể.

Crawler > Sitemap Settings

  • Custom Sitemap – LSC có thể crawl trước website của bạn tự động nhưng tôi thích nhập vào sitemap với các website lớn hoặc có nhiều kiểu bài post, cần phải đảm bảo là nó không phí thời gian cho các url không quan trọng. Bạn có thể sử dụng sitemap của riêng bạn chẳng hạn như cái được tạo từ plugin XML sitemap. Hoặc có thể nếu bạn muốn sử dụng crawler sitemap riêng (chẳng hạn như loại trừ một số mục nhất định không cần pre-crawl).
  • Drop Domain from Sitemap – cứ để nó là ON trừ khi bạn có nhiều tên miền trong sitemap (chẳng hạn như multisite, multi-lingual).
  • Include Posts/Pages/Cats/Tags – thường bạn nên để là ON, trừ khi bạn muốn loại trừ một số mục có lưu lượng truy cập thấp không cần crawling trước.
  • Exclude Custom Post Types – phần này bao gồm các mục mà bạn không muốn đưa vào trong sitemap của bạn. Bạn nên loại trừ tất cả liên kết mà bình thường URL của chúng không được truy cập trực tiếp. Lấy ví dụ, nếu bạn có trang “FAQs / Các câu hỏi thường gặp” nhưng nó thường được duyệt qua các trang khác, thế thì bạn có thể loại trừ chúng ở đây. Ý tưởng ở đây là loại bỏ càng nhiều link khỏi sitemap thì càng tốt để các crawler (như LSC hoặc Google) có thể tập trung vào các nội dung có lưu lượng truy cập cao hơn.
  • Order links by – “Date, descending / Ngày, giảm dần” là cái có hữu ích nhất đối với tôi trừ khi trong một số trường hợp mà nội dung cũ lại có giá trị hơn, hoặc nội dung của bạn được sắp xếp theo bảng chữ cái abc.

Toolbox > Purge

Tôi thích khu vực này vì nó có các tùy chọn purge chuyên sâu; nó có khả năng lựa chọn purging tinh tế vì thế bạn không làm quá tải trên các máy chủ có lưu lượng truy cập cao (khi hàng ngàn người dùng sẽ truy cập vào các trang chưa được cache). Nhưng trên đa số website tôi không bao giờ dùng tính năng này. Tôi đơn giản là purge mọi thứ một lần.

  • Tất cả các tùy chọn ở đây đều đã tự giải thích ý nghĩa của nó khi bạn chỉ cần nhìn vào tên của chúng.
  • Những cái đáng chú ý có lẽ là pages, CSS/JS, và Opcode cache. Đây là những thứ phổ biến nhất mà các trang web lớn hay purging hàng ngày (day-to-day).
  • Lưu ý thêm: nếu bạn có ý định cấu hình trang của bạn chỉ để purging thủ công, đừng quên vô hiệu hóa các quy tắc purge tự động trong mục cache!

Toolbox > Import/Export

Đây là khu vực tiện lợi cho việc kiểm tra và lưu các cấu hình khác nhau mà bạn có. Tôi có sử dụng nó không? Không, bởi vì tôi đã cấu hình LSC trên hàng trăm website nên thạo lắm rồi.

Một câu hỏi mà tôi được hỏi rất nhiều là bạn có thể lưu một cấu hình chung và nhập nó vào tất cả các trang web của bạn? Bạn có thể nhưng chỉ cho các cấu hình không có nhu cầu tùy chỉnh riêng. Tôi không bao giờ sử dụng nó, tôi thích cài đặt thủ công để đảm bảo chắc chắn.

  • Export – lưu tất cả các cài đặt thành file LSC tiện lợi
  • Import – nhập cài đặt từ file cài đặt LSC.
  • Reset Settings – resets tất cả các cài đặt LSC về mặc định.

Toolbox > Edit .htaccess

Tôi thích tính năng này. Rất tiện lợi để xem và sửa nhanh file .htacess mà không cần phải vào máy chủ thông qua FTP. Thực sự hữu ích khi muốn xử lý sự cố hoặc khi bạn muốn dọn dẹp hoặc chỉnh sửa .htaccess.

  • .htaccess Path Settings – tự động phát hiện nên hoạt động tốt. Chỉ định đường dẫn thường không cần thiết trừ khi website của bạn nằm trong một số thư mục không tiêu chuẩn hoặc đang dùng tên file .htaccess không chuẩn.
  • Current .htaccess Contents – hãy sử dụng nó cẩn thận!

Toolbox > Heartbeat Control

Trước khi bạn máy mó mày mò với heartbeat controls trong WordPress, bạn cần phải hiểu nó được dùng vào việc gì đã. WordPress heartbeat là lời gọi AJAX sử dụng file “/wp-admin/admin-ajax.php”. Hầu hết các trang không bao giờ phải tối ưu hóa cái này trừ khi nó gây ra vấn đề sử dụng CPU cao (nhìn thấy các lời gọi admin-ajax.php chậm từ waterfalls khi kiểm tra tốc độ).

Trong trường hợp bạn cần tối ưu hóa nó, hãy cẩn trọng về cách thực hiện. Bạn không nên vô hiệu hóa nó hoàn toàn trừ khi các lời gọi không cần thiết đến từ một số plugin cồng kềnh. Thường thì, chúng ta tối ưu hóa tăng tần số ở những nơi nó được dùng và vô hiệu hóa nó từ các trang không sử dụng.

Hai trường hợp sử dụng phổ biến nhất cho heartbeat là (A) các bài viết tự động lưu trong khi bạn biên tập và (B) cập nhật số lượng hàng trong giỏ ở WooCommerce khi mọi người thêm/bớt sản phẩm. Có rất nhiều trường hợp sử dụng khác nữa nhưng nó sẽ thay đổi từ trang này sang trang khác phụ thuộc vào plugin nào được sử dụng. Bạn chỉ cần cẩn thận trước khi vô hiệu hóa nó!

  • Frontend Heartbeat Control – để nó là ON nếu bạn muốn thay đổi interval.
  • Frontend Heartbeat TTL – có thể nhân đôi lên thành 120 giây nếu nó vẫn được dùng trên frontend hoặc thiết lập là 0 để vô hiệu hóa.
  • Backend Heart Control – bật nó là ON nếu bạn muốn thay đổi interval.
  • Backend Heartbeat TTL – thường thì backend đủ an toàn để vô hiệu hóa hoàn toàn heartbeat vì phần lớn chức năng không dựa vào nó.
  • Editor Heartbeat – tôi đặc biệt khuyến cáo bạn nên để nó là OFF vì WordPress sử dụng nó để tự động lưu công việc của bạn. Nếu chẳng may internet của bạn bị cắt đột ngột hoặc bạn chẳng may đóng trang, vân vân…công việc của bạn sẽ vẫn được lưu.
  • Editor Heartbeat TTL – bạn có thể gia tăng interval nếu bạn có nhiều người viết trên trang cùng một lúc, nhưng đừng bao giờ vô hiệu hóa nó!

Toolbox > Report

  • Install DoLogin Security – plugin hữu ích cho phép người khác truy cập vào WP-admin sử dụng liên kết tạm thời (thay cho việc sử dụng đăng nhập user/pass).
  • LiteSpeed Report – hữu ích cho việc gửi thông tin đến trung tâm hỗ trợ chính chức của LS.
  • Passwordless Link – tạo ra liên kết đăng nhập tự động cho WP-admin. Yêu cầu cài plugin bảo mật DoLogin đề cập ở trên.
  • Notes – đưa thêm vào bất cứ thông tin hữu ích nào. Chẳng hạn bạn làm gì, bạn thay đổi cái gì, bạn thấy vấn đề ở đâu và cách để tạo lại nó.
  • Send to LiteSpeed – gửi báo cáo cho LiteSpeed. Sau đó bạn trích dẫn số của báo cáo trong diễn đàn hỗ trợ hoặc bất cứ chỗ nào mà bạn tạo ra được yêu cầu hỗ trợ.

Toolbox > Debug

Bạn không nên thay đổi bất cứ điều gì ở đây trừ khi bạn đang debugging (gỡ lỗi) vấn đề với trang của bạn. Thành thật mà nói, tôi chưa bao giờ phải sử dụng nó vì hầu hết các vấn đề liên quan đến caching tôi có thể sửa chữa dễ dàng.

  • Disable All Features – chỉ để nó là ON khi bạn gỡ lỗi vấn đề.
  • Debug Log – để nó là ON chỉ khi bạn gỡ lỗi. Sử dụng tùy chọn Admin IP nếu bạn có rất nhiều lưu lượng truy cập khiến cho debug log quá lớn.
  • Admin IPs – nhập vào IP ngoài của bạn để chạy debug từ trình duyệt.
  • Debug Level – lựa chọn Basic hoặc Advanced tùy thuộc vào nhu cầu của bạn.
  • Log File Size Limit – tăng chỉ khi bạn cần nó.
  • Log Cookies – để ON nếu cần thiết.
  • Collapse Query Strings – để ON nếu cần.
  • Debug URI Includes – nhật ký trên các trang được liệt kê. Hữu ích nếu bạn chỉ có một số vấn đề trên một trang cụ thể nào đó.
  • Debug URI Excludes – lợi trừ các trang khỏi debug log của bạn.

Toolbox > Log View

  • [D] Clear Log – xóa log.
  • Clear Log – xóa log.

Toolbox > Beta Test

Đây là tùy chọn hữu ích nếu bạn muốn kiểm tra các phiên bản khác nhau của LiteSpeed Cache (tốt nhất là trên trang staging) và chuyển đổi qua lại giữa BETA và các phiên bản ỔN ĐỊNH. Tôi nghĩ nó cũng có thể hữu ích cho việc quay trở lại phiên bản trước đó nếu phiên bản mới gặp vấn đề.

  • Use latest GitHub commit – click vào để thử phiên bản mới nhất trên GitHub.
  • Use latest WordPress release version – click vào để sử dụng phiên bản ỔN ĐỊNH nhất của LSC.

Bước 3 – Kiểm tra xem LiteSpeed Cache có hoạt động bình thường hay không?

  1. Mở trang web của bạn trên trình duyệt bất kỳ (không đăng nhập)
  2. Tải và tải lại một vài trang.
  3. Sau đó xem mã nguồn, cuộn chuột xuống dưới cuối và xem xem liệu LiteSpeed Cache có để lại chú thích không.

Chú thích của nó sẽ có kiểu như thế này (chỉ cache):

<!-- Page generated by LiteSpeed Cache 3.2.4 on 2020-07-24 18:13:20 -->

Hoặc thế này (cache và rút gọn HTML):

<!-- Page optimized by LiteSpeed Cache @2020-07-22 13:17:33 -->
<!-- Page generated by LiteSpeed Cache 3.2.4 on 2020-07-22 20:17:33 -->

Trong đó 3.2.4 là phiên bản của plugin, còn đoạn đằng sau là ngày giờ nó tạo cache.

Đương nhiên, trang có thể chậm đôi chút với lần ghé thăm lần đầu tiên nhưng phải phải nhanh thấy rõ với các lần truy cập tiếp theo.

Bước 4 – Giải quyết lỗi

  • LiteSpeed cache comment not showing (không hiển thị chú thích của LiteSpeed) – có thể vì LSC không hoạt động hoặc bạn đang bật đang bật tính năng loại bỏ chú thích HTML của Cloudflare.
  • CSS trì hoãn gặp vấn đề (FOUC hoặc FOUT) – bạn không sử dụng critical CSS và đừng kết hợp các file CSS nữa!
  • Broken visuals or functions (hỏng giao diện hoặc chức năng) – thử thôi không kết hợp CSS hoặc JS. Hoặc bạn có thể sử dụng các bước chuẩn đoán mà tôi trình bày dưới đây để phát hiện và loại trừ CSS/JS có vấn đề.
  • Contact forms not working (form liên hệ không hoạt động) – nếu form liên hệ của bạn không hoạt động cách sửa đơn giản nhất là loại trừ (exclude) trang đó hoàn toàn. Cách khác là cần đảm bảo loại trừ kết hợp CSS/JS khỏi trang liên hệ. (Tôi cũng khuyến cáo luôn là bạn không nên sử dụng Contact Form 7).
  • WSOD hoặc lỗi error 500 – thật không may nhưng không phải mọi plugin đều tương thích với nhau. Bạn có thể khôi phục trang của bạn bằng cách xóa phần thông tin của LScache trong htaccess, xóa các file “advanced-cache.php” và “object-cache.php” trong thư mục “wp-content”. Bạn cũng có thể gia tăng giới hạn của bộ nhớ WP.
  • Admin area showing incorrectly (khu vực quản trị hiển thị không chính xác) – điều này có thể là do caching dành cho người dùng đã đăng nhập, caching nội dung riêng tư, hoặc object-caching. Thử vô hiệu hóa tất cả và bật lại dần từng cái một cho đến khi bạn tìm ra vấn đề.

Làm thế nào tìm và loại trừ được các vấn đề đến từ việc kết hợp CSS/JS:

  1. Phương thức cô lập A – vấn bật chế độ KẾT HỢP CSS hoặc JS, mở website trong trình duyệt Chrome > Developer Tools > Network (tab), và tải lại trang. Click vào vòng tròn lỗi nhỏ màu đỏ để xem CSS/JS nào bị thiếu. Loại trừ chúng không cho gộp và xem mọi thứ có hoạt động bình thường không.
  2. Phương thức cô lập B – vô hiệu hóa KẾT HỢP CSS hoặc JS (hoặc thậm chí là cả caching), và quét trang của bạn trong Pingdom. Cuộn xuống bảng waterfall và sắp xếp các mục tải về theo kiểu file (hiển thị gọn gàng tất cả CSS/JS). Giờ bạn quay lại cài đặt của LiteSpeed và gộp file CSS/JS lần nữa nhưng loại trừ thủ công bất cứ file CSS/JS nào mà bạn nghĩ là nguyên nhân gây lỗi. (Gợi ý: bất cứ cái gì bị hỏng có thể liên quan đến vấn đề. Có phải một plugin hoặc chức năng theme nào đó ngừng hoạt động? Thử vô hiệu hóa các file CSS/JS đó). Vâng bạn sẽ phải thực hiện nhiều thử nghiệm và thất bại. Nó có thể có nguyên nhân từ bất cứ đâu, có thể là plugin, có thể là theme.

Có nhiều cái tôi không muốn nói ra vì nó quá kỹ thuật và chỉ nên được xử lý với người dùng trình độ cao. Nếu bạn có nhiều vấn đề với việc gộp CSS/JS, bạn không nên sử dụng tính năng này nữa. Đó chẳng phải lỗi của ai cả…không phải của bạn, không phải của plugin cache, cũng không phải của theme hay plugin. (Chắc chắn bạn có thể thử plugin gộp CSS/JS khác như Autoptimize và nó có thể hoạt động cho cài đặt của bạn bây giờ nhưng sau đó có thể gặp vấn đề vào hôm xấu trời nào đó). Tôi thực sự thực sự không khuyến khích gộp CSS/JS!

Bước 5 – Thực hành với tối ưu hóa mức cao

Chiến lược kết hợp CSS/JS

Một lần nữa, tôi ghét kết hợp CSS/JS nhưng nếu bạn thực sự muốn làm nó…Tôi nghĩ bạn nên thử nghiệm kết hợp CSS/JS với các trang thực sự nhỏ hoặc thực sự lớn. Nếu trang của bạn nằm đâu đó ở giữa, bạn có thể có được hiệu suất tốt hơn nhiều và vận hành không rắc rối bằng cách không quan tâm đến kết hợp CSS/JS chút nào cả. Nếu trang của bạn thực sự nhỏ (giả sử với 5 file CSS nhưng chỉ tổng dung lượng chỉ 7KB), kết hợp chúng thành một yêu cầu duy nhất không có gì rắc rối (ít có khả năng xảy ra mâu thuẫn), và cũng giúp tăng tốc bởi vì có ít yêu cầu HTTP hơn. Còn nếu trang của bạn thực sự lớn (giả sử với 20 file CSS và tổng dung lượng lên đến 800 KB), nó có thể đem lại lợi ích nhỏ cho một số trang nhưng không phải tất cả.

Giờ, đây là lý do tại sao tôi không khuyến khích kết hợp tất cả CSS/JS hoặc trên các website lớn: đó là bởi vì chúng có quá nhiều CSS/JS mà không thể tải trong một lần. Và làm trì hoãn quá trình kết xuất (rendering) trang bằng cách đợi tất cả chúng tải về thật ngớ ngẩn. Đó là lý do tại sao chúng ta nên kết hợp một số nhưng không phải tất cả. Và điều quan trọng hơn, chúng ta quyết định cái nào cần tải trước tiên.

Có 2 chiến thuật cơ bản:

  • Kết hợp tất cả và loại trừ một số – điều này có ý nghĩa nhất và phù hợp nhất với cách plugin cache vận hành. Tôi gợi ý bạn nên kết hợp tất cả CSS/JS và loại trừ cái nào cần thiết nhất cho việc kết xuất phần đầu của trang.
  • Kết hợp một số, loại trừ phần còn lại – cái này thậm chí còn an toàn hơn khi chỉ vài file CSS/JS sẽ được kết hợp, hạn chế xảy ra mâu thuẫn, nhưng sẽ yêu cầu bạn làm việc vất vả hơn một chút để chỉ định thủ công các file nào cần loại trừ.

Bạn có thể lưu ý đến chuyện tôi không đề cập đến critical CSS chút nào trong phần trên. Lý do tôi ghét tạo critical CSS vì nó có thể rất khó khăn, kỳ công (finicky). Đừng sử dụng nó trừ khi bạn chắc chắn biết bạn đang định làm gì. Và nếu bạn đang sử dụng nó rồi, thì tôi sẽ không giải thích cách sử dụng nó ở đây nữa.

Chiến lược Object-Caching

Tôi chỉ khuyến khích điều này cho các trang web lớn với nhiều truy vấn cơ sở dữ liệu và nội dung động có thể cache trong ngắn hạn (short-term). Bất cứ cái gì có số lượng lớn thông tin và tương đối “sống/live” hoặc “động” là dấu chỉ tốt cho object caching. Bật nó và sử dụng redis. Sau đó hãy thoải mái thử nghiệm với thời gian hết hạn của object cache phù hợp với bạn và không phục vụ nội dung quá hạn (outdated content). Tôi cũng nghe nói hiệu suất tốt hơn khi sử dụng redis trong socket Unix (mặc dù tôi chưa bao giờ làm điều này). Đây là hướng dẫn dành cho người quản trị hệ thống (admin-guys).

Lưu ý: nếu phần lớn nội dung của bạn là tĩnh và số lượng nội dung không bao giờ thay đổi, thế thì bạn không cần object caching!

Bật crawler (hoặc các chứ năng làm ấm cache thay thế khác)

Bạn có bao giờ để ý là các plugin cache khác cho phép caching trước, tải trước, hoặc làm ấm cache? Tôi chắc chắn thích tính năng đó vì nó ngăn lượt ghé thăm đầu tiên bị chậm. Thật không may, LiteSpeed Cache được xây dựng để hỗ trợ cho máy chủ LiteSpeed thường được dùng cho các trang có lưu lượng truy cập cao mà ở đó không cần lo lắng về việc làm ấm cache (vì lượt ghé thăm đầu tiên đã làm ấm/tạo cache cho tất cả những người còn lại)…nhưng với các trang có lưu lượng truy cập thấp, cache thường không có trong một thời gian cho đến khi có ai đó ghé thăm.

Vì thế bạn có 2 lựa chọn:

  • Bạn có thể bật LS cache crawler từ máy chủ – nhưng điều này yêu cầu truy cập vào máy chủ và một số kỹ năng Linux để cài đặt/cấu hình nó. Một khi được cài đặt, bạn sau đó có thể thiết lập crawler tích cực hoặc vừa phải trong chuyện thu thập như ý bạn muốn.
  • Sử dụng chức năng làm ấm thay thế – tôi giả định là bạn không có khả năng truy cập vào máy chủ và webhost của bạn không muốn bật tính năng crawler. Họ sợ bạn làm tổn hao tài nguyên của máy chủ. Vì thế lựa chọn thay thế cho bạn là sử dụng plugin kiểu như Warm Cache cái cache trước trang của bạn được xác định trong sitemap XML (từ plugin SEO của bạn như YOAST, hoặc plugin sitemap như Google XML Sitemap) sử dụng cron jobs đặt ở tần số bạn chọn.

Caching nội dung riêng tư

Có rất nhiều thông tin bạn có thể tham khảo. Tôi sẽ để nó ở đây cho bạn (và/hoặc lập trình viên của bạn).

Cần sự giúp đỡ từ chuyên gia?

Tôi đã làm hết sức mình để cung cấp lời khuyên chi tiết cho tất cả mọi người. Nhưng luôn luôn có các trang cần cấu hình riêng. Bạn vẫn gặp rắc rối? Hãy ghé thăm một trong các kênh hỗ trợ cho LiteSpeed đề cập bên dưới.

(Dịch từ bài viết: LiteSpeed Cache WordPress Plugin – UNOFFICIAL GUIDE của Johnny Nguyen, người dịch: Nguyễn Đức Anh)

Back to Top