Câu chuyện cải thiện tốc độ cảm nhận bằng cách cố định hàm Vercel về khu vực Tokyo — giải quyết việc phải đi vòng qua Thái Bình Dương

Tóm tắt bài viết

Nguyên nhân dashboard chậm là do "hàm Vercel đặt tại Mỹ, còn DB đặt tại Tokyo", khiến mỗi lần xử lý đều phải đi vòng qua Thái Bình Dương

Có thể kiểm tra hàm được thực thi ở khu vực nào thông qua response header x-vercel-id

Bằng cách cố định khu vực Tokyo qua regions trong vercel.json kết hợp song song hóa truy vấn, thời gian đo nội bộ đã rút ngắn từ vài giây xuống còn khoảng 0,2 giây

Đây là ghi chép về việc điều tra và xác định nguyên nhân của cảm giác "chuyển màn hình dashboard mất vài giây", sau đó tiến hành cải thiện. Chúng tôi đã phân tách vấn đề dựa trên số liệu đo thực tế, chứ không phải dựa trên phỏng đoán.

Triệu chứng và cách phân tách vấn đề

Việc chuyển màn hình mất khoảng 3 giây. Trước tiên, chúng tôi phân tách xem đâu là phần chậm giữa "phản hồi khởi động của server (TTFB)" và "việc lấy nội dung dữ liệu", và phát hiện rằng khởi động thì nhanh, còn việc lấy dữ liệu bên trong trang mới là phần chậm.

Bản thân từng truy vấn trên database lại rất nhanh, chỉ mất vài mili-giây. Vậy mà tổng thể lại chậm. Điều chúng tôi nghi ngờ lúc này chính là vị trí thực thi (khu vực/region).

Nguyên nhân 1: Phải đi vòng qua Thái Bình Dương

Khi kiểm tra response header x-vercel-id, chúng tôi phát hiện hàm được thực thi tại khu vực miền Đông nước Mỹ (iad1). Trong khi đó, database (Supabase) lại đặt tại Tokyo. Nói cách khác, mỗi lần truy vấn đều phát sinh việc đi lại giữa Nhật Bản và Mỹ.

Header trông như sau (minh họa).

x-vercel-id: hnd1::iad1   ← Điểm tiếp nhận là Tokyo (hnd1) nhưng thực thi lại ở Mỹ (iad1)

Nếu có vài truy vấn, mỗi lần đều phải đi vòng qua Thái Bình Dương, và độ trễ (latency) cứ thế cộng dồn.

Nguyên nhân 2: Chờ truy vấn theo kiểu tuần tự

Một điểm khác là màn hình trang chủ đang lấy nhiều số liệu tổng hợp theo kiểu tuần tự (lần lượt từng cái một). Đây là tình trạng độ trễ của việc đi vòng cứ thế cộng dồn theo đúng số lần thực hiện.

Giải pháp

Cố định khu vực về Tokyo

Chúng tôi đã thêm chỉ định khu vực vào vercel.json, để hàm được thực thi tại Tokyo (hnd1).

{ "regions": ["hnd1"] }

Nhờ vậy, x-vercel-id trở thành hnd1::hnd1, cả hàm và DB đều nằm ở Tokyo. Độ trễ do việc đi vòng đã được giải quyết.

Song song hóa truy vấn

Chúng tôi đã song song hóa các thao tác lấy số liệu tổng hợp vốn đang chờ tuần tự bằng Promise.all, đồng thời gộp các thao tác lấy dữ liệu bị trùng lặp thành một.

Kết quả

Theo số liệu đo nội bộ, thời gian hiển thị màn hình trang chủ đã được rút ngắn từ vài giây xuống còn khoảng 0,2 giây. Điểm mấu chốt là tốc độ xử lý tự thân được cải thiện, chứ không dựa vào cache. Dữ liệu hiển thị luôn là dữ liệu mới nhất.

Bài học rút ra

Khi gặp tình huống "truy vấn thì nhanh nhưng màn hình lại chậm", đừng chỉ nghi ngờ tốc độ của DB mà hãy nghi ngờ cả khoảng cách vật lý giữa hàm và DB (khu vực/region).
x-vercel-id là manh mối đơn giản mà mạnh mẽ để kiểm tra khu vực thực thi.
Trong môi trường có chi phí đi vòng cao, việc chờ tuần tự sẽ trở thành yếu tố gây hại nghiêm trọng. Hiệu quả của song song hóa là rất lớn.

Tổng kết

Nguyên nhân thực sự của cảm giác chậm chính là việc đi vòng giữa Mỹ và Tokyo. Chỉ với hai giải pháp là cố định khu vực và song song hóa, chúng tôi đã cải thiện đáng kể tốc độ cảm nhận mà không cần dùng đến cache. Nếu bạn cảm thấy SSR hoặc dashboard của mình đang chậm, hãy thử kiểm tra mối quan hệ vị trí giữa khu vực thực thi và DB trước tiên.