Tăng tốc WordPress bằng Redis, Nginx và cache cần bắt đầu từ việc phân biệt dữ liệu được lưu ở đâu. Theo tài liệu WordPress, persistent object cache giúp giảm những lần truy cập cơ sở dữ liệu; trong khi cache phản hồi của Nginx cho phép tái sử dụng kết quả từ máy chủ phía sau. Hai cơ chế giải quyết những phần khác nhau của quá trình phục vụ trang, nên cần cấu hình và kiểm tra riêng.
Hướng dẫn dưới đây đề xuất triển khai từng lớp trên môi trường thử nghiệm trước khi áp dụng cho website thật. Đây là quy trình tham khảo dựa trên tài liệu chính thức, chưa phải kết quả benchmark của một hệ thống cụ thể. Trước khi sửa, hãy lưu bản cấu hình đang hoạt động và chuẩn bị cách khôi phục. Không nên đặt mục tiêu tăng tốc theo một tỷ lệ cố định khi chưa có số đo của chính website.
Phân biệt cache trang và cache đối tượng
Tài liệu WP_Object_Cache giải thích rằng object cache mặc định chỉ tồn tại trong thời gian xử lý một yêu cầu. Muốn tái sử dụng dữ liệu qua nhiều lượt tải trang, WordPress cần cơ chế persistent cache phù hợp. Chỉ thêm WP_CACHE vào cấu hình không tự tạo ra khả năng này. Vì vậy, bước kiểm tra đầu tiên là xác định website đã có plugin và backend lưu đối tượng lâu dài hay chưa.
Với cache trang, mục tiêu là tái sử dụng phản hồi đã tạo thay vì yêu cầu hệ thống dựng lại cùng nội dung. WordPress mô tả lợi ích giảm xử lý máy chủ của việc phục vụ trang đã lưu; Nginx cung cấp cơ chế lưu phản hồi từ upstream. Từ đó, có thể chọn thử cache cho nội dung công khai trước, rồi đánh giá riêng Redis ở những luồng vẫn phải chạy WordPress. Đây là cách phân chia phép thử, không phải cam kết lớp nào luôn hiệu quả hơn.
Kết nối Redis và đặt giới hạn rõ ràng
Redis Object Cache yêu cầu Redis Server đã hoạt động. Theo hướng dẫn của dự án, sau khi cài và kích hoạt plugin, người quản trị vào Settings → Redis để bật cache và kiểm tra kết nối. Với ví dụ Redis nằm cùng máy, có thể khai báo các dòng sau trong wp-config.php, trước phần nạp wp-settings.php:
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_PREFIX', 'website-a:' );
Đây là ví dụ có điều kiện; hãy thay địa chỉ, cổng và tiền tố theo hệ thống thực tế, đồng thời tránh khai báo trùng hằng số đã có.
Nếu đã có WP-CLI và plugin tương ứng, thực hiện từng bước trong thư mục website bằng tài khoản quản trị phù hợp:
Bước 1: wp redis status
Bước 2: wp redis enable
Bước 3: wp redis status
Tài liệu và mã nguồn dự án xác nhận các lệnh kiểm tra, bật và tắt object cache. Sau khi bật, nên thử cả trang công khai lẫn thao tác quản trị. Nếu cần hoàn tác lớp này, dùng wp redis disable rồi kiểm tra lại chức năng và trạng thái.
Redis cũng cần ngân sách bộ nhớ. Tài liệu Redis quy định maxmemory cho giới hạn dữ liệu và maxmemory-policy cho cách xử lý khi chạm giới hạn. Ví dụ tham khảo cho một instance chuyên lưu cache là:
maxmemory 256mb
maxmemory-policy allkeys-lru
Con số 256 MB chỉ minh họa, không phải yêu cầu phần cứng hoặc mức đủ cho mọi website. Chính sách allkeys-lru có thể loại bỏ khóa ít được truy cập gần đây; vì vậy không áp dụng máy móc cho instance chứa dữ liệu cần giữ lâu dài.
Về kết nối, tài liệu bảo mật Redis khuyến nghị chỉ cho các client tin cậy truy cập. Trường hợp ứng dụng và Redis cùng máy, loopback là một phương án được tài liệu mô tả; không cần mở Redis ra Internet để khách đọc website sử dụng. Hãy giữ kiểm soát mạng trong suốt quá trình thử. Cũng không dùng FLUSHALL như thao tác hoàn tác thông thường: tài liệu Redis cảnh báo lệnh này có thể xóa toàn bộ tập dữ liệu.
Bật Nginx cache với điều kiện bỏ qua và đường lui
Nginx phân biệt hai quyết định: có lấy phản hồi từ cache hay không, và có lưu phản hồi mới vào cache hay không. Với FastCGI, các chỉ thị tương ứng là fastcgi_cache_bypass và fastcgi_no_cache; tài liệu cache proxy cũng mô tả hai quyết định tương tự. Khi thiết kế quy tắc cho WordPress, nên lập danh sách riêng cho đăng nhập, quản trị, phiên người dùng và các trang có dữ liệu cá nhân. Mỗi trường hợp cần được kiểm tra bằng tài khoản thử, thay vì chỉ nhìn trang chủ.
Không nên sao chép một cấu hình FastCGI cache rời rạc vào mọi máy chủ. Tài liệu Nginx cho thấy cache còn phụ thuộc vùng lưu trữ, khóa cache, thời gian hiệu lực và điều kiện bỏ qua. Đề xuất thực hành là yêu cầu cấu hình hoàn chỉnh phù hợp với luồng xử lý PHP hiện có, rồi đối chiếu từng điều kiện với website. Chỉ chuyển sang bước bật khi đã có cách nhận biết nội dung nào được phép dùng chung và cách kiểm tra sau khi cập nhật bài.
Trước khi nạp thay đổi, dùng nginx -t với đúng bản Nginx và tệp cấu hình của dịch vụ. Tài liệu chính thức xác nhận tùy chọn này kiểm tra cú pháp và thử mở các tệp được tham chiếu. Chỉ khi kiểm tra thành công mới nạp lại bằng cơ chế quản lý dịch vụ đang dùng; nginx -s reload là một lựa chọn khi phù hợp với cách cài đặt. Nếu cần hoàn tác, khôi phục cấu hình đã lưu, kiểm tra lại rồi nạp lại.
Bài kiểm tra nghiệm thu nên gồm hai lượt tải cùng trang công khai, một lượt đăng nhập, một thao tác sửa nội dung và một lần hoàn tác thử. Ghi lại kết quả trước và sau từng lớp để quyết định giữ cấu hình nào. Kiểm tra cú pháp Nginx và trạng thái Redis là những bước riêng; đừng dùng chúng thay cho việc xác nhận người đọc nhận đúng nội dung. Chỉ mở rộng phạm vi cache sau khi các tình huống thực tế của website đã được kiểm tra.
