Giải thích cho người mới · 10/2026

Đường đi của
một yêu cầu

Từ cú nhấp chuột đến cơ sở dữ liệu: bảy chặng, chặng nào chậm, và cách đo bằng curl trước khi nhờ AI sửa.

Ví dụ đời thường Chạy thật Bài tập có đáp án Danh sách kiểm
GET /slow Chậm ở đâu?
Câu hỏi của bài này

Trang chậm không phải một lỗi

1Trang chậm là tổng của bảy chặng. Thường chỉ một chặng chiếm gần hết thời gian.
2Đo từng chặng, đừng đoán. Một lệnh curl cho ra các mốc thời gian.
3Đo trước, rồi mới nhờ AI sửa. Hệ thống thật phức tạp hơn bản đồ này, nên các hình ảnh chỉ để dễ nhớ.
Hình dung trước

Bảy việc trước khi nhận hàng

Đi
  • 1. Tra danh bạ tìm địa chỉ (DNS)
  • 2. Gọi điện báo có đơn (kết nối)
  • 3. Chung nhau thùng có khóa (TLS)
  • 4. Gửi phiếu đặt hàng (HTTP)
Ở cửa hàng và đường về
  • 5. Lễ tân xử lý phiếu (ứng dụng)
  • 6. Xuống kho tìm hàng (cơ sở dữ liệu)
  • 7. Hàng giao về tay bạn (phản hồi)
Hàng đến chậm? Người đáng tin là người bấm giờ từng cửa.
Từ khó, nói dễ

Sáu từ sẽ gặp trong bài

DNS

tên kỹ thuật: hệ thống tên miền

Danh bạ của internet: đưa tên, nhận địa chỉ số của máy chủ.

Kết nối

tên kỹ thuật: TCP

Cuộc gọi báo trước. Bên kia nghe máy rồi mới gửi hàng.

Thùng có khóa

tên kỹ thuật: TLS, trong địa chỉ https

Hai bên thỏa thuận khóa trước, người ngoài không xem được.

Phiếu và mã

tên kỹ thuật: HTTP, mã trạng thái

Phiếu đặt hàng và phiếu trả. Số ngắn: 200 xong, 404 không thấy, 500 lỗi.

Cơ sở dữ liệu

tên kỹ thuật: database

Cái kho lưu thông tin lâu dài. Ứng dụng phải hỏi kho mới có dữ liệu.

Độ trễ

tên kỹ thuật: latency

Thời gian chờ, tính bằng giây hoặc mili giây (một phần nghìn giây).

Bản đồ

Bảy chặng của một yêu cầu

1

DNS

Tra danh bạ. Hay chậm khi máy chủ DNS xa.

2

Kết nối

Gọi báo trước. Hỏng: bị từ chối, hết giờ.

3

TLS

Thùng có khóa. Hỏng: chứng chỉ hết hạn.

4

Yêu cầu

Phiếu đặt hàng. Hỏng: thiếu quyền, 401, 403.

5

Ứng dụng

Lễ tân xử lý. Hỏng: lỗi 500.

6

Cơ sở dữ liệu

Xuống kho. Chậm khi hỏi quá nhiều lần.

7

Phản hồi

Giao hàng về. Chậm khi nội dung lớn.

Mỗi chặng chậm hoặc hỏng riêng. Thông báo lỗi là manh mối.

Ba chặng đầu

Ba chặng đầu: tra, gọi, khóa

1 · DNS

Hỏi danh bạ để đổi tên thành địa chỉ số. Kết quả thường được nhớ tạm, nên lần sau nhanh hơn.

2 · TCP

Gọi báo trước và chờ bên kia nghe máy. Máy chủ xa hoặc mạng mất gói thì chậm hoặc bị từ chối.

3 · TLS

Chung nhau chiếc thùng có khóa trong địa chỉ https. Chứng chỉ hết hạn thì trình duyệt cảnh báo.

Kết nối đã mở thường được dùng lại: yêu cầu sau hay bỏ qua ba chặng này.
Chặng 4

Phiếu đặt hàng và phiếu trả hàng

GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 29769
Năm nhóm mã
  • 1xx thông tin, 2xx thành công
  • 3xx chuyển hướng
  • 4xx lỗi phía người gửi
  • 5xx lỗi phía máy chủ

Mẫu theo MDN. 200 chỉ nói yêu cầu thành công về giao thức, chưa nói nội dung đúng.

Chặng 5 và 6

Hỏi kho một lần hay 100 lần?

Cách một
51

truy vấn: một cho danh sách, rồi một cho từng dòng

Cách hai
1

truy vấn có phép nối, cùng một đáp án

Đếm thật bằng SQLite. Mỗi chuyến 5 mili giây là giả định của tôi: 255 so với 5 mili giây.

Chờ máy chủ dài? Câu đầu tiên: trang này gửi bao nhiêu truy vấn?
Đo bằng curl

Năm mốc thời gian của curl

1time_namelookupTra DNS xong
2time_connectKết nối TCP xong
3time_appconnectBắt tay TLS xong
4time_starttransferNhận byte đầu tiên, gồm cả thời gian máy chủ
5time_totalXong toàn bộ
Tất cả đếm từ lúc bắt đầu, không phải thời gian của riêng chặng đó.
Cách tính

Mốc cộng dồn nên phải trừ

DNS = namelookup
TCP = connect - namelookup
TLS = appconnect - connect
Chờ = starttransfer - appconnect
Tải = total - starttransfer

Lấy mốc sau trừ mốc liền trước. Dùng nguyên time_total làm một chặng là hiểu sai.

Khoảng chờ máy chủ gồm cả ứng dụng và cơ sở dữ liệu. curl không tách được hai phần này.

Chạy thật

Chạy thật: cùng tổng, khác thủ phạm

ChặngCa A: cơ sở dữ liệu chậmCa B: DNS chậm
DNS0,0451,205
Kết nối0,0350,035
TLS0,0640,065
Chờ máy chủ0,8050,055
Tải về0,0240,023
Tổng (giây)0,9731,383

Mô phỏng chạy thật. Độ trễ do tôi đặt sẵn, không phải đo từ mạng.

Ca A: chờ chiếm gần 83%. Ca B: DNS chiếm gần 87%. Sửa sai chỗ thì vô ích.

Chỉ nhìn tổng thì không phân biệt được hai ca.
Ví dụ tính được

Tính thử: phần của chặng lớn nhất

A: 0.805 / 0.973 = 0.83
B: 1.205 / 1.383 = 0.87
N+1: 601 * 5 ms = 3005 ms

Số 5 mili giây mỗi truy vấn là giả định. Các độ trễ ca A và B do tôi đặt.

Chặng lớn nhất chiếm 83% ở ca A và 87% ở ca B.

601 truy vấn nhỏ chờ 3.005 mili giây, khớp với trang mất gần 3 giây.

Bài tập có đáp án

Bài tập: tìm chặng chậm

python3 slow_app.py

curl -s -o /dev/null -w \
'tcp=%{time_connect}
first_byte=%{time_starttransfer}
code=%{http_code}\n' \
http://127.0.0.1:8765/slow
Câu hỏi

Chặng nào chiếm gần hết thời gian? Tính bằng phép trừ.

Đáp án suy từ code

first_byte trừ tcp xấp xỉ 0,8 giây, vì code chờ 0,8 giây trước khi trả lời.

Tôi chưa chạy được máy chủ này vì môi trường chặn cổng mạng. Bạn chạy thật và so với đáp án.

Chỗ dễ nhầm

Năm chỗ dễ nhầm

1Trang chậm nên sửa cơ sở dữ liệu ngayCó thể DNS hoặc TLS mới là chặng dài. Đo trước.
2Chỉ nhìn mã 200Thân phản hồi vẫn có thể rỗng hoặc chứa lỗi.
3Lần hai nhanh nên coi là xongBộ nhớ tạm làm lần sau nhanh. Đo cả lần đầu.
4Dùng time_total làm thời gian một chặngCác mốc cộng dồn. Luôn lấy mốc sau trừ mốc trước.
5Chỉ đo một lầnMạng dao động. Đo nhiều lần, lấy trung vị.
Minh họa, không có thật

Minh họa: trang báo cáo chậm

Đoán rồi sửa
09:40 · DevLàm cho truy vấn nhanh hơn.
09:45 · AgentĐã thêm chỉ mục. Đã tối ưu.
10:05 · DevVẫn chậm: first_byte 3,05 giây.
Đo rồi mới sửa
10:15 · Nhật ký601 truy vấn, mỗi cái chờ khoảng 5 ms.
10:50 · DevGộp thành một truy vấn, in số truy vấn trước và sau.
10:55 · Agent601 xuống 1. first_byte còn khoảng 0,1 giây.
Đo trước, rồi đưa số đo cho AI. Chỉ nói “nhanh hơn” thì AI có thể sửa sai chỗ.
Danh sách kiểm

Tám câu hỏi khi trang chậm

1Tôi đo bằng số hay đang đoán?
2Tôi đã trừ các mốc chưa?
3Chặng nào lớn nhất?
4Lần đầu hay lần sau? Đã đo nhiều lần chưa?
5Mã trạng thái và nội dung có đúng không?
6Chờ máy chủ dài thì trang gửi bao nhiêu truy vấn?
7Đã đưa số đo cho AI và đòi số đo sau sửa?
8Tôi đo từ đâu, người dùng có ở gần đó không?
Nhìn cân bằng

Nhìn cân bằng: được gì, chưa được gì

Làm được
  • Cho cách chia vấn đề thành các chặng
  • Cho công thức đo bằng phép trừ
  • Tập thói quen đo trước khi nhờ AI
Chưa làm được
  • Là bản đồ đơn giản hóa: còn CDN, proxy, HTTP/3
  • curl đo một nơi, một lần. Chưa đo mạng thật, bài tập chưa chạy
  • Chưa có nghiên cứu đo N+1 trong code do AI viết
Kết luận

Trang chậm: đo từng chặng, trừ các mốc, rồi mới sửa.

Nếu chặng lớn nhất là chờ máy chủ, đếm số truy vấn trước khi đoán. Khi nhờ AI sửa, đưa số đo cho nó và tự mở số đo sau khi sửa.