Website chậm sau khi nâng cấu hình

Website vẫn chậm sau khi đã nâng CPU, RAM hoặc chuyển sang gói máy chủ mạnh hơn là tình huống khá phổ biến. Điều này thường khiến đội ngũ vận hành cho rằng cấu hình mới chưa đủ mạnh và tiếp tục tăng tài nguyên. Tuy nhiên, nếu bottleneck thực sự nằm ở database, Disk I/O, application worker, cache, network hoặc frontend thì việc nâng cấu hình có thể chỉ làm chi phí tăng mà tốc độ website gần như không thay đổi.

Một website chỉ nhanh hơn sau khi nâng cấu hình khi tài nguyên vừa được tăng chính là điểm nghẽn trước đó. Nếu CPU chưa từng bị sử dụng cao, việc tăng từ 4 vCPU lên 8 vCPU có thể không tạo ra khác biệt đáng kể. Tương tự, nếu RAM vẫn còn nhiều, tăng thêm bộ nhớ không giúp một truy vấn database mất 3 giây trở thành 300 ms.

Bài viết này hướng dẫn cách kiểm tra website vẫn chậm sau khi nâng cấu hình, từ việc xác nhận server đã nhận đúng tài nguyên mới đến khoanh vùng frontend, web server, application, database, cache, Disk I/O và các dịch vụ bên ngoài.

Nguyên tắc quan trọng: Nâng cấu hình chỉ giải quyết vấn đề khi bottleneck nằm ở tài nguyên được nâng. Nếu website vẫn chậm, hãy quay lại dữ liệu monitoring và xác định điểm nghẽn thay vì tiếp tục tăng cấu hình theo cảm tính.

Xác nhận máy chủ đã nhận đúng cấu hình mới

Trước khi phân tích sâu hơn, cần chắc chắn Cloud Server hoặc VPS thực sự đã nhận tài nguyên mới.

Kiểm tra CPU:

nproc

Hoặc:

lscpu

Kiểm tra RAM:

free -h

Kiểm tra ổ đĩa:

lsblk

Kiểm tra filesystem:

df -h

Có trường hợp volume đã được mở rộng ở tầng hạ tầng nhưng filesystem bên trong hệ điều hành vẫn chưa được mở rộng. Khi đó dung lượng mới chưa thể sử dụng đầy đủ.

Nếu sử dụng container, cũng cần kiểm tra container có bị giới hạn riêng hay không:

docker stats

Một Cloud Server có 16 GB RAM nhưng container chỉ được giới hạn 2 GB vẫn có thể gặp lỗi thiếu bộ nhớ.

So sánh dữ liệu trước và sau khi nâng cấu hình

Không nên đánh giá hiệu quả chỉ bằng cảm giác.

Cần so sánh cùng một bộ chỉ số:

Chỉ số	Trước nâng cấp	Sau nâng cấp
TTFB	Ghi lại baseline	Đo lại
P95 response time	Ghi lại baseline	Đo lại
CPU peak	Ghi lại baseline	Đo lại
RAM available	Ghi lại baseline	Đo lại
Disk latency	Ghi lại baseline	Đo lại
Error rate	Ghi lại baseline	Đo lại
RPS	Ghi lại baseline	Đo lại
Database connection	Ghi lại baseline	Đo lại

Nếu CPU giảm rõ rệt nhưng response time gần như không đổi, CPU có thể không phải bottleneck chính.

Nếu RAM tăng nhưng website vẫn chậm đúng như trước, cần kiểm tra database, Disk I/O hoặc application.

Kiểm tra TTFB trước khi nhìn frontend

TTFB cao thường cho thấy request mất nhiều thời gian trước khi server bắt đầu trả dữ liệu.

Có thể kiểm tra:

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}\nTotal: %{time_total}\n' https://example.com

Nếu TTFB vẫn cao sau khi nâng cấu hình, cần kiểm tra các tầng phía sau:

Nginx
   |
   v
Application
   |
   v
Database / Cache / External API

Ngược lại, nếu TTFB thấp nhưng trang vẫn mất nhiều giây mới hiển thị hoàn chỉnh thì bottleneck có thể nằm ở frontend, hình ảnh hoặc JavaScript.

CPU tăng chưa chắc website sẽ nhanh hơn

CPU chỉ giúp khi workload thực sự thiếu năng lực xử lý.

Ví dụ trước khi nâng:

CPU trung bình: 35%
CPU peak: 55%

Nếu tăng CPU gấp đôi, website có thể gần như không thay đổi vì CPU chưa từng đạt giới hạn.

CPU thường trở thành bottleneck khi:

• Application xử lý tính toán nặng.
• PHP-FPM worker tiêu thụ CPU cao.
• Node.js process đạt giới hạn.
• Java application dùng CPU lớn.
• Compression hoặc image processing nặng.
• Background worker cạnh tranh CPU.

Kiểm tra:

top

Hoặc:

htop

Xem process dùng CPU nhiều:

ps aux --sort=-%cpu | head

Nếu CPU còn nhiều nhưng request vẫn chậm, cần chuyển sang kiểm tra các thành phần khác.

Tăng RAM không giải quyết mọi vấn đề

RAM thường bị hiểu nhầm là “càng nhiều thì website càng nhanh”.

Thực tế, RAM chủ yếu tạo khác biệt khi hệ thống thiếu bộ nhớ hoặc có thể sử dụng bộ nhớ bổ sung cho cache, database buffer hoặc worker.

Kiểm tra:

free -h

Kiểm tra swap:

swapon --show

Nếu trước khi nâng RAM:

Available memory vẫn cao
Swap gần như không dùng

thì tăng RAM có thể không cải thiện response time.

Ngược lại, nếu hệ thống thường xuyên swap hoặc bị OOM Kill, tăng RAM có thể tạo khác biệt rõ rệt.

Kiểm tra OOM:

dmesg | grep -i -E 'oom|killed process'

Application worker vẫn có thể là giới hạn

Một server có thêm CPU và RAM nhưng số worker không thay đổi thì application chưa chắc tận dụng được tài nguyên mới.

Ví dụ PHP-FPM chỉ có:

pm.max_children = 10

Dù server được tăng từ 4 lên 8 vCPU, nếu cả 10 worker đều bận thì request mới vẫn phải chờ.

Cần kiểm tra:

• Số worker.
• Worker utilization.
• Request queue.
• RAM mỗi worker.
• Request timeout.
• Slow request.

Với PHP:

ps aux | grep php-fpm

Với Node.js, cần kiểm tra số process hoặc cluster worker.

Với Java, cần kiểm tra thread pool, connection pool và garbage collection.

Không nên tăng worker tùy ý. Worker nhiều hơn đồng nghĩa RAM và database connection cũng có thể tăng.

Database có thể là bottleneck thật sự

Đây là một trong những nguyên nhân phổ biến nhất khiến website vẫn chậm sau khi nâng máy chủ application.

Một request có thể đi theo luồng:

Web Server: 20 ms
Application: 50 ms
Database: 2.500 ms

Trong trường hợp này, tăng CPU application gần như không giải quyết được 2,5 giây của database.

Các vấn đề thường gặp:

• Thiếu index.
• Slow query.
• Query quét toàn bảng.
• N+1 query.
• JOIN trên bảng lớn.
• Lock.
• Deadlock.
• Connection pool không phù hợp.
• Database nằm trên storage chậm.
• Query báo cáo chạy trên production.

Với MySQL có thể kiểm tra:

SHOW PROCESSLIST;

Nếu đã bật slow query log, cần tìm query tốn nhiều thời gian nhất.

Có thể kiểm tra execution plan:

EXPLAIN SELECT ...;

Không nên tăng cấu hình application trước khi xác định database có đang là điểm nghẽn hay không.

Disk I/O có thể làm server mạnh vẫn chậm

CPU và RAM có thể còn dư nhưng application vẫn phải chờ ổ đĩa.

Điều này thường xảy ra khi:

• Database đọc ghi nhiều.
• Log tăng nhanh.
• Backup chạy cùng giờ traffic cao.
• Swap.
• Container ghi log lớn.
• Storage có latency cao.
• Ổ đĩa gần đầy.

Kiểm tra:

iostat -xz 1

Theo dõi:

• I/O wait.
• Read latency.
• Write latency.
• Utilization.
• Queue.

Kiểm tra dung lượng:

df -h

Kiểm tra inode:

df -i

Nếu Disk I/O là bottleneck, tăng CPU và RAM không trực tiếp giải quyết vấn đề.

Website có thể đang thiếu cache

Một website không sử dụng cache hiệu quả có thể bắt application và database xử lý lại cùng một dữ liệu cho mọi request.

Ví dụ:

1.000 request
   |
   v
1.000 lần chạy PHP
   |
   v
1.000 lượt query database

Nếu có page cache hoặc object cache:

1.000 request
   |
   |-- phần lớn trả từ cache
   |
   `-- một phần nhỏ xuống backend

Cần kiểm tra:

• Page cache.
• Redis.
• Memcached.
• FastCGI Cache.
• CDN cache.
• Cache-Control.
• TTL.
• Cache hit ratio.

Nếu Redis được sử dụng, có thể kiểm tra:

redis-cli INFO stats

Cache hit thấp khiến phần lớn request vẫn phải xuống database dù server đã được nâng cấu hình.

CDN không được cấu hình đúng

Website có thể vẫn chậm vì toàn bộ static asset vẫn đi trực tiếp từ origin.

Kiểm tra trong DevTools:

F12 -> Network

Xem:

• Domain phục vụ ảnh.
• CSS.
• JavaScript.
• Font.
• Response header.
• Cache status.

Có thể kiểm tra bằng:

curl -I https://example.com/image.webp

Nếu CDN luôn trả MISS hoặc BYPASS, cần kiểm tra lại:

• Cache rule.
• Cookie.
• Query string.
• TTL.
• Cache-Control.
• Purge cache.

Nâng Cloud Server không làm hình ảnh ở xa người dùng tự động tải nhanh hơn nếu static asset vẫn được phân phối trực tiếp từ một origin.

Hình ảnh và frontend vẫn có thể là nguyên nhân

Một server phản hồi HTML trong 200 ms nhưng trang vẫn mất 5 giây để hiển thị hoàn chỉnh nếu frontend quá nặng.

Các nguyên nhân:

• Ảnh vài MB.
• JavaScript lớn.
• Nhiều third-party script.
• Tracking.
• Font lớn.
• CSS render-blocking.
• Chat widget.
• Video autoplay.

Kiểm tra:

F12 -> Network
F12 -> Performance

Theo dõi:

• Largest file.
• Main thread.
• Long task.
• Render blocking.
• Total transferred.

Nếu frontend là bottleneck, tăng CPU server gần như không tác động tới trải nghiệm này.

Kiểm tra Nginx hoặc Apache

Web server có thể có giới hạn riêng.

Với Nginx:

sudo nginx -t
sudo systemctl status nginx

Kiểm tra connection:

ss -s

Xem error log:

sudo tail -f /var/log/nginx/error.log

Các cấu hình cần kiểm tra:

• Worker process.
• Worker connections.
• Keepalive.
• Proxy timeout.
• FastCGI timeout.
• Compression.
• Static cache.

Nếu application server được tăng tài nguyên nhưng Nginx vẫn bị giới hạn connection, hệ thống vẫn có thể nghẽn tại tầng web server.

Connection pool chưa được điều chỉnh

Sau khi tăng số application worker, database connection có thể trở thành giới hạn tiếp theo.

Ví dụ:

20 worker
x
10 connection mỗi worker
=
200 connection

Nếu database chỉ cho phép 150 connection, request có thể bắt đầu chờ hoặc lỗi.

Cần kiểm tra:

• Max connection database.
• Pool size.
• Idle connection.
• Connection timeout.
• Connection leak.

Đây là ví dụ điển hình cho việc tăng một tài nguyên làm bottleneck chuyển sang thành phần khác.

API bên ngoài vẫn chậm

Website có thể phụ thuộc:

• Payment gateway.
• CRM.
• Shipping API.
• SMS.
• Email.
• Maps.
• AI API.
• Analytics.

Nếu request phải chờ một API bên ngoài 3 giây:

Application
    |
    v
External API
    |
    `-- 3 giây

thì tăng CPU từ 4 lên 16 vCPU vẫn không làm API bên ngoài phản hồi nhanh hơn.

Cần kiểm tra:

• Timeout.
• Retry.
• Response time.
• Circuit breaker.
• Fallback.
• Queue.

Các tác vụ không cần phản hồi ngay nên cân nhắc chuyển sang background processing.

Cronjob hoặc backup vẫn chạy vào giờ cao điểm

Có trường hợp website chỉ chậm vào một số thời điểm dù cấu hình đã được nâng.

Nguyên nhân có thể là:

• Backup.
• Database dump.
• Import sản phẩm.
• Sync dữ liệu.
• Generate report.
• Reindex.
• Log rotation.

Kiểm tra:

crontab -l

Và:

ls -la /etc/cron.d/

Nếu một job nặng chạy đúng giờ traffic cao, CPU hoặc Disk I/O có thể bị cạnh tranh.

Giải pháp có thể đơn giản là chuyển job sang khung giờ tải thấp hơn.

Kiểm tra traffic có tăng sau khi nâng cấu hình không

Một trường hợp dễ bị bỏ qua là sau khi nâng cấu hình, traffic đồng thời cũng tăng.

Ví dụ trước nâng cấp:

100 RPS
CPU 90%

Sau nâng cấp:

250 RPS
CPU 75%

Website vẫn có thể chậm vì workload mới lớn hơn nhiều.

Do đó cần so sánh hiệu năng tại cùng mức tải, không chỉ so sánh hai thời điểm khác nhau.

Các chỉ số nên đối chiếu:

• RPS.
• Concurrent user.
• Response time.
• CPU.
• RAM.
• Database connection.
• Error rate.

Kiểm tra bot và crawler

Một server mới có nhiều tài nguyên hơn có thể xử lý nhiều request hơn, nhưng bot vẫn có thể tiêu thụ phần tài nguyên vừa được bổ sung.

Kiểm tra IP tạo nhiều request:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Kiểm tra URL bị gọi nhiều:

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Nếu có lượng request bất thường, có thể cân nhắc:

• Rate limiting.
• WAF.
• Bot management.
• Cache.
• Chặn endpoint không cần thiết.

Kiểm tra container limit nếu sử dụng Docker

Một Cloud Server được nâng cấu hình không đồng nghĩa container tự động sử dụng toàn bộ tài nguyên.

Kiểm tra:

docker stats

Kiểm tra cấu hình container:

docker inspect container_name

Nếu Compose có cấu hình giới hạn CPU hoặc RAM, cần kiểm tra lại.

Ngoài ra cần xem:

• Restart count.
• Container log.
• Volume.
• Network.
• Health check.

Container có thể restart vì memory limit dù host còn nhiều RAM.

Load test lại sau khi nâng cấu hình

Cách tốt nhất để xác định cấu hình mới có thực sự cải thiện hệ thống hay không là chạy lại cùng một kịch bản load test.

Ví dụ:

Trước nâng cấp:
200 RPS -> P95 = 1,8 giây

Sau nâng cấp:
200 RPS -> P95 = 1,7 giây

Mức cải thiện rất nhỏ cho thấy CPU hoặc RAM có thể không phải bottleneck.

Nếu:

Trước:
200 RPS -> lỗi 10%

Sau:
400 RPS -> lỗi 0,5%

thì cấu hình mới đã tăng capacity rõ rệt, dù một số trang vẫn có thể chậm vì nguyên nhân khác.

Load test nên theo dõi:

• RPS.
• P95.
• P99.
• Error rate.
• CPU.
• RAM.
• Disk I/O.
• Database connection.
• Queue.
• Cache hit.

Checklist xử lý website vẫn chậm sau khi nâng cấu hình

Xác nhận hạ tầng

• CPU mới đã được nhận.
• RAM mới đã được nhận.
• Volume đã mở rộng.
• Filesystem đã mở rộng.
• Container không bị giới hạn cũ.

Backend

• TTFB đã được đo lại.
• CPU được theo dõi theo thời gian.
• RAM và swap đã được kiểm tra.
• Disk I/O đã được kiểm tra.
• Application worker đã được kiểm tra.
• Nginx hoặc Apache không bị giới hạn.

Database

• Đã kiểm tra slow query.
• Đã kiểm tra index.
• Đã kiểm tra connection pool.
• Đã kiểm tra lock.
• Đã kiểm tra database latency.

Cache

• Page cache hoạt động.
• Redis hoặc object cache hoạt động.
• CDN có cache HIT.
• TTL hợp lý.
• Không purge cache quá thường xuyên.

Frontend

• Ảnh đã được tối ưu.
• JavaScript không quá lớn.
• Third-party script đã được kiểm tra.
• Static asset được cache.
• CDN được sử dụng nếu phù hợp.

Vận hành

• Cronjob không chạy vào peak.
• Backup không gây I/O cao.
• Bot và crawler đã được kiểm tra.
• External API đã được đo response time.
• Load test đã được chạy lại.

Khi nào tiếp tục nâng cấu hình?

Chỉ nên tiếp tục scale up nếu dữ liệu cho thấy tài nguyên hiện tại thực sự đang đạt giới hạn.

Ví dụ:

CPU duy trì cao
+
RPS tăng
+
Response time tăng theo CPU

hoặc:

RAM không đủ
+
Swap tăng
+
Application bị OOM

Nếu bottleneck nằm ở database, cache hoặc frontend, tăng cấu hình server có thể không phải bước tiếp theo phù hợp.

Khi một server đã được tối ưu nhưng không còn đủ khả năng xử lý, có thể cân nhắc scale out:

User
 |
 v
Load Balancer
 |
 |-- App Server 1
 |-- App Server 2
 `-- App Server 3
      |
      v
Database / Cache

Trước khi scale out cần đảm bảo application có thể chạy nhiều instance, session không phụ thuộc local và file upload không chỉ nằm trên một server.

Kết luận

Website vẫn chậm sau khi nâng cấu hình thường cho thấy CPU, RAM hoặc tài nguyên vừa được nâng không phải bottleneck duy nhất của hệ thống.

Một quy trình xử lý phù hợp nên đi theo thứ tự:

Xác nhận cấu hình mới
->
Đo lại TTFB và response time
->
Kiểm tra CPU/RAM/Disk
->
Kiểm tra worker
->
Kiểm tra database
->
Kiểm tra cache/CDN
->
Kiểm tra frontend
->
Load test lại

Không nên tiếp tục tăng cấu hình nếu chưa biết request đang mất thời gian ở đâu. Một query chậm, Disk I/O cao, connection pool nhỏ hoặc JavaScript nặng đều có thể khiến website chậm dù máy chủ đã được nâng cấp mạnh hơn.

Quan trọng nhất là đo cùng một workload trước và sau thay đổi. Khi xác định đúng bottleneck, đội ngũ mới có thể quyết định nên tối ưu application, database, cache, CDN, storage hay tiếp tục mở rộng Cloud Server.