Casestudy: Tối Ưu Hệ Thống WordPress Doanh Nghiệp: Hành Trình Từ 40s Còn 0.5s

Vừa rồi mình nhận nhiệm vụ kiểm tra và tối ưu hệ thống cho một blog WordPress của doanh nghiệp hoạt động trong lĩnh vực Internet tại Việt Nam. Website có lượng truy cập lớn và thường xuyên bị chậm hoặc quá tải khi chạy chiến dịch marketing — dù đã có đội dev riêng rất mạnh tối ưu code, database, caching kỹ lưỡng.

OK, Challenge Accepted! Bắt tay vào việc thôi!

I. Kiểm Tra Sơ Bộ

Trước tiên cần đo thời gian xử lý index.php để làm mốc đánh giá hiệu quả tối ưu:

time php index.php

⏱ Kết quả: 30–40 giây — quá chậm!

Kiểm tra tài nguyên server:

  • RAM: Còn dư nhiều
  • CPU Load: Cao hơn số core hiện có → thiếu CPU
  • Disk IO: Tốt (SSD)
  • Mô hình: Reverse Proxy (nginx + apache)
  • PHP handler: Apache dùng mod_php
  • top cho thấy httpd chiếm 100% CPU thường xuyên

Nhận định: CPU chiếm dụng cao ở user & system space. Không do I/O vì %iowait thấp.

Kết luận tổng quan:

  • Hệ thống quá tải CPU trong xử lý PHP
  • mod_php xử lý mỗi request bằng một process httpd
  • Khi có traffic lớn (chiến dịch marketing), nhiều process sinh ra → hết RAM, CPU cao, queue dài, delay tăng

II. Phân Tích Cách Server Xử Lý PHP

Sử dụng strace để xem các system call liên quan khi xử lý index.php:

strace -c php index.php

Phát hiện bất thường:

  • gettimeofday được gọi hơn 1,300,000 lần, chiếm 96.96%
  • gettimeofday: Lấy timestamp (giây & microgiây) → khả năng liên quan đến caching hoặc debug

Nghi ngờ plugin W3 Total Cache, kiểm tra source code:

III. Bất Ngờ Xảy Ra

Vì nghi ngờ plugin vẫn ảnh hưởng, mình xóa hẳn thư mục w3total_cache → kết quả vẫn vậy!
Phát hiện: gettimeofday() trong PHP chưa chắc là system call cùng tên của kernel

Chạy lại strace và lưu log chi tiết:

strace -o output.txt php index.php

Phát hiện mới: gettimeofday xuất hiện khi mở file hoặc cấp phát bộ nhớ mới → giống hành vi debug log

IV. NewRelic

Phát hiện NewRelic được cài đặt — một công cụ APM theo dõi hiệu suất ứng dụng:

  • Sử dụng timestamp để ghi metrics → gọi gettimeofday thường xuyên
  • Metrics dạng (timestamp, key => value) → cần thời gian chuẩn xác từng hành động

Lần theo tiếp, phát hiện thêm Xdebug cũng được cài!

V. Xdebug

Xdebug record toàn bộ function call & biến → cực kỳ ngốn tài nguyên

Nhiều báo cáo xác nhận Xdebug gây giảm hiệu năng, spam gettimeofday

Tắt Xdebug và kiểm tra lại

Bingo!

  • gettimeofday biến mất khỏi top call
  • CPU usage giảm rõ rệt
  • Thời gian xử lý chỉ còn vài giây

VI. Chưa Thể Dừng Lại

Vẫn còn system call như lstat, open, fstat gọi quá nhiều → truy cập file chưa tối ưu

Kiểm tra hệ thống:

  • PHP 5.6
  • Chưa có Opcache!

Nâng cấp lên PHP 7.2 + enable Opcache

Thời gian xử lý giảm còn 0.5 giây

VII. Tổng Kết

  • Giảm thời gian xử lý: 40s → 0.5s
  • Giảm hơn 1.3 triệu system call thừa
  • Hệ thống ổn định, sẵn sàng cho các chiến dịch lớn

p/s: Bài viết gốc được mình viết từ năm 2020, nay đăng lại nên có thể một số thông tin hơi outdate một chút nha!

Cheers,
Nguyễn Hưng – Bo Vietnix

Thẻ

Bài viết liên quan