DPTCloud
Quay lại danh sách
Tin tức công nghệ

Tối ưu hóa PHP-FPM và Nginx trên Ubuntu: Bí quyết xử lý 50.000+ truy cập đồng thời cho Chiến dịch Landing Page

27 tháng 5, 2026

Giới thiệu: Thử thách chịu tải lớn trong các chiến dịch Marketing

Trong các chiến dịch quảng bá sản phẩm hoặc Flash Sale, Landing Page chính là vũ khí chiến lược để chuyển đổi khách hàng tiềm năng. Tuy nhiên, một kịch bản ác mộng thường xuyên xảy ra: quảng cáo vừa chạy, lượng truy cập tăng vọt đột biến, và hệ thống sập hoàn toàn. Khách hàng đối mặt với lỗi 502 Bad Gateway hoặc 504 Gateway Timeout, khiến doanh nghiệp tổn thất lớn về chi phí marketing và uy tín thương hiệu.

Để xử lý mượt mà hơn 50.000 lượt truy cập đồng thời (concurrent requests), việc nâng cấp cấu hình phần cứng VPS thôi là chưa đủ. Chìa khóa nằm ở việc tối ưu hóa cách thức phối hợp giữa Nginx và PHP-FPM trên nền tảng Ubuntu. Bài viết này sẽ hướng dẫn bạn từng bước cấu hình chuyên sâu để vắt kiệt hiệu năng phần cứng, đảm bảo hệ thống luôn vững vàng trước mọi cơn bão traffic.

1. Nguyên lý hoạt động và kiến trúc hệ thống lý tưởng

Trước khi đi vào cấu hình, chúng ta cần hiểu rõ luồng xử lý: Nginx đóng vai trò là Web Server tiếp nhận các kết nối từ người dùng. Đối với các tài nguyên tĩnh (hình ảnh, CSS, JS), Nginx sẽ tự xử lý cực kỳ nhanh chóng. Đối với các tài nguyên động (PHP), Nginx sẽ chuyển tiếp qua Unix Socket đến PHP-FPM để xử lý và trả lại kết quả.

Quy tắc cốt lõi: Hãy sử dụng Unix Socket thay vì TCP Port (127.0.0.1:9000) cho sự giao tiếp giữa Nginx và PHP-FPM nhằm giảm thiểu overhead của giao thức mạng và tối ưu hóa tốc độ phản hồi.

2. Tối ưu hóa cấu hình Nginx (nginx.conf)

Nginx nổi tiếng với khả năng xử lý bất đồng bộ (Asynchronous Event-driven). Để tận dụng tối đa sức mạnh này, hãy chỉnh sửa tệp cấu hình chính tại /etc/nginx/nginx.conf.

Tối ưu hóa Worker Processes và Connections

  • worker_processes auto;: Cho phép Nginx tự động nhận diện và tận dụng toàn bộ số lõi CPU của VPS.
  • worker_connections 10240;: Số lượng kết nối đồng thời tối đa mà một worker process có thể xử lý. Với 50.000 truy cập, con số này cần được nâng cao (ví dụ: 10240 hoặc hơn tùy thuộc vào giới hạn hệ thống).
  • multi_accept on;: Cho phép một worker tiếp nhận tất cả các kết nối mới cùng một lúc trong hàng đợi.

Cấu hình Timeouts và Buffers

Khi traffic tăng cao, việc duy trì các kết nối treo hoặc quá hạn sẽ làm cạn kiệt tài nguyên hệ thống. Hãy áp dụng cấu hình sau:


keepalive_timeout 30;
client_header_timeout 15;
client_body_timeout 15;
send_timeout 15;
client_max_body_size 10m;
client_body_buffer_size 128k;

Kích hoạt Gzip và FastCGI Cache

Để giảm tải cho PHP-FPM, việc bật FastCGI Cache là bắt buộc đối với Landing Page ít thay đổi dữ liệu động. Điều này cho phép Nginx lưu lại phản hồi của PHP và trả về trực tiếp cho các lượt truy cập sau mà không cần gọi lại PHP-FPM.


fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;

3. Tối ưu hóa cấu hình PHP-FPM (www.conf)

PHP-FPM là nơi xử lý các logic phức tạp và thường là điểm nghẽn (bottleneck) lớn nhất. Hãy truy cập vào tệp cấu hình pool (thường tại /etc/php/{version}/fpm/pool.d/www.conf).

Lựa chọn Process Manager (pm)

Đối với một chiến dịch Landing Page cần độ phản hồi ngay lập tức cho 50.000 truy cập, chế độ pm = static là lựa chọn tối ưu nhất. Thay vì bật/tắt các tiến trình liên tục gây lãng phí CPU, hệ thống sẽ duy trì cố định một số lượng lớn PHP worker luôn sẵn sàng chiến đấu.

Tính toán các thông số PHP Worker

Công thức tính số lượng tiến trình tối đa (pm.max_children) dựa trên lượng RAM trống khả dụng của VPS:

pm.max_children = (Tổng RAM khả dụng - RAM cho các dịch vụ khác) / Kích thước trung bình của một PHP process

Ví dụ: Nếu VPS có 16GB RAM trống và mỗi PHP process chiếm khoảng 40MB, bạn có thể thiết lập:

  • pm = static
  • pm.max_children = 350
  • pm.max_requests = 2000 (Tự động khởi động lại worker sau 2000 request để tránh rò rỉ bộ nhớ).

4. Điều chỉnh thông số Kernel hệ thống (sysctl.conf)

Hệ điều hành Ubuntu mặc định không được thiết kế để xử lý lượng kết nối khổng lồ của một máy chủ web cấp doanh nghiệp. Chúng ta cần nới rộng các giới hạn này tại /etc/sysctl.conf:


# Tăng số lượng kết nối tối đa trong hàng đợi
net.core.somaxconn = 65535

# Tăng giới hạn số lượng file có thể mở cùng lúc
fs.file-max = 2097152

# Tối ưu hóa việc tái sử dụng các kết nối TCP
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.core.netdev_max_backlog = 65536

Sau khi lưu tệp, chạy lệnh sudo sysctl -p để các thay đổi có hiệu lực ngay lập tức.

5. Kiểm thử tải (Load Testing) và Giám sát

Sau khi hoàn tất cấu hình, việc quan trọng nhất là phải giả lập kịch bản chịu tải trước khi chiến dịch chính thức bắt đầu. Bạn có thể sử dụng các công cụ chuyên dụng như Locust, ApacheBench (ab), hoặc k6 để bắn thử nghiệm 50.000 request vào hệ thống.

Trong quá trình test, hãy theo dõi sát sao hiệu năng thông qua các lệnh hệ thống như htop để xem mức tiêu thụ CPU/RAM, và kiểm tra file log /var/log/nginx/error.log để phát hiện kịp thời các lỗi phát sinh.

Kết luận

Việc tối ưu hóa Nginx và PHP-FPM không phải là một công thức cố định mà đòi hỏi sự linh hoạt dựa trên cấu hình phần cứng cụ thể của doanh nghiệp. Bằng cách áp dụng mô hình kết nối Unix Socket, chuyển đổi sang cấu hình pm = static cho PHP-FPM, tận dụng tối đa cơ chế FastCGI Cache của Nginx và nới rộng giới hạn kết nối của Kernel Ubuntu, bạn hoàn toàn có thể tự tin vận hành những chiến dịch Landing Page quy mô lớn, mang lại trải nghiệm mượt mà cho hơn 50.000 khách hàng cùng lúc, tối đa hóa tỷ lệ chuyển đổi và doanh thu.