Bạn từng thắc mắc tại sao web chỉ có 5-10 người online mà server CPU đã nhảy lên 100%? Đó là vì User ≠ Request. Bài viết này giải thích sự khác biệt và cách tối ưu tài nguyên.

User vs Request: Khái niệm

User Online là gì?

User Online là người đang mở website trên trình duyệt. Họ có những khoảng nghỉ tự nhiên: đọc bài, xem ảnh, scroll… mà không tương tác với server.

Request là gì?

Request là yêu cầu trình duyệt gửi đến server để lấy dữ liệu. Một user không chỉ tạo 1 request — mà có thể tạo 50-100 requests để load một trang web hoàn chỉnh.

Tại sao 1 User tạo ra nhiều Request?

Khi user nhấn vào trang chủ, trình duyệt gửi:

• 1 request → file HTML
• 10-20 requests → CSS, JavaScript
• 20-50 requests → hình ảnh, icon, fonts
• Nhiều requests ngầm → AJAX, heartbeat, tracking

Ví dụ: Trang WordPress với theme đầy đủ có thể tạo 80-150 requests cho 1 user.

Sức nặng của Request

Không phải request nào cũng nhẹ. Có request “nhẹ” như lấy ảnh, và request “nặng” có thể chiếm 50% CPU:

Ví dụ: Tìm kiếm sản phẩm

• User gõ từ khóa → nhấn Enter (1 request)
• Server chạy PHP xử lý
• SQL query tìm trong 100,000 sản phẩm
• Nếu database không có index → quét toàn bộ dữ liệu
• Kết quả: 1 request có thể chiếm 50% CPU trong 2-3 giây

Nếu user đó nhấn F5 liên tục, họ có thể tự làm treo server.

Các trường hợp thực tế

1. Plugin WordPress tạo nhiều requests

Nhiều plugin gửi request liên tục: kiểm tra link hỏng, quét bảo mật, hiển thị lượt xem real-time…

• Heartbeat API: Gửi request mỗi 15 giây
• Plugin bảo mật: Scan liên tục
• Kết quả: 5 users nhưng tần suất request = 500 users

2. Bot và Crawler

Bot không hiện trong “User Online” nhưng gửi hàng nghìn requests mỗi phút:

• Googlebot
• Bingbot
• Bot spam, scraper

3. File nặng chưa tối ưu

1 file ảnh 10MB chưa nén:

• User truy cập → server gửi 10MB
• Process treo trên server cho đến khi gửi xong
• Chiếm RAM, băng thông, I/O

Giải pháp tối ưu

1. Cài đặt Cache

# Cache biến request nặng thành nhẹ
# PHP + SQL → HTML tĩnh

# LiteSpeed Cache / WP-Rocket / W3TC
# Hoặc Nginx FastCGI Cache

# Đo lường:
# Trước: TTFB 2-3 giây
# Sau: TTFB 50-100ms

2. Sử dụng CDN

# CDN gánh bớt request từ server gốc
# Cloudflare, AWS CloudFront, Vercel

# Hình ảnh, CSS, JS được cache ở edge
# Server gốc chỉ xử lý HTML

3. Tối ưu Database

# Thêm index cho cột thường query
ALTER TABLE products ADD INDEX idx_name (product_name);
ALTER TABLE products ADD INDEX idx_category (category_id);

# Query chậm → EXPLAIN để xem
EXPLAIN SELECT * FROM products WHERE name LIKE '%keyword%';

4. Rate Limiting

# Nginx rate limit
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location / {
    limit_req zone=api burst=20 nodelay;
}

# Hoặc dùng Fail2ban chặn IP spam

5. Tối ưu hình ảnh

# Nén ảnh trước khi upload
# JPEG: 80% quality
# PNG: dùng TinyPNG

# Lazy loading
# 

# Responsive images
# 

6. Chặn Bot không cần thiết

# robots.txt
User-agent: *
Disallow: /wp-admin/
Disallow: /?s=

# Cloudflare Bot Management
# Hoặc .htaccess chặn IP đáng ngờ

Monitoring Requests

# Xem top IPs gửi nhiều requests
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -20

# Xem requests theo status code
awk '{print $9}' access.log | sort | uniq -c

# Xem slow queries
tail -f /var/log/mysql/slow.log

# Cloudflare Analytics
# Dashboard → Analytics → Traffic

So sánh User vs Request

Kết Luận

So sánh: User Online giống như số người ngồi trong quán. Request giống như số món họ gọi. Một người gọi 100 món cùng lúc làm đầu bếp kiệt sức hơn 10 người mỗi người gọi 1 món.

• Đừng chỉ nhìn User Online — hãy check access log để xem thực tế
• Tối ưu từng Request: nén ảnh, dùng cache, chặn bot
• Giới hạn rate để tránh user/bot làm quá tải

Kết hợp với Cache là gì và Caching Strategies để tối ưu toàn diện.