Này những người lỗi máy chủ,
Hãy tưởng tượng một công ty "Phần mềm dưới dạng dịch vụ" chung cung cấp dịch vụ chạy trên AWS (này, đó là chúng tôi). Không có khoa học tên lửa nào liên quan, ứng dụng web tiêu chuẩn hoạt động như bình thường và ứng dụng điện thoại thông minh của người dùng cuối. Vì khách hàng đến từ Châu Âu, đương nhiên là khu vực AWS eu-central-1 chứa mọi thứ dành cho nhiều đối tượng thuê.
Bây giờ Bộ phận bán hàng quản lý để giành được một khách hàng từ Châu Úc - tất cả đều tốt cho đến nay, vì ứng dụng web đã có thể xử lý các múi giờ, đơn vị tiền tệ và ngôn ngữ khác nhau. Nhưng: Úc cách xa châu Âu nhất có thể (ít nhất là trên trái đất), và do đó, hiện có khá nhiều thời gian khứ hồi. Mỗi yêu cầu, chúng tôi thấy khoảng 300 mili giây - 400 mili giây bổ sung cho mỗi hướng (CHỈNH SỬA: điều này là sai khi nói về RTT như đã chỉ ra trong phần khen ngợi, chúng tôi thấy 2x400ms = 800ms thêm cho lần đầu tiên HTTPS yêu cầu).
Đối với ứng dụng web được đề cập, được khách hàng sử dụng cho mục đích quản lý, nó hoàn toàn ổn.HTML được kết xuất sẽ xuất hiện muộn hơn một chút nhưng nhờ có CDN (CloudFront), nội dung không phải là vấn đề.
Tuy nhiên, ứng dụng điện thoại thông minh của người dùng cuối, vốn thực hiện các yêu cầu JSON nhỏ hơn nhưng nhiều hơn, sẽ bị ảnh hưởng. Ở đó, nó cảm thấy ở rìa của "OK-ish" nhưng chắc chắn không linh hoạt.
Bây giờ câu hỏi là: cách cải thiện thời gian từ góc độ người dùng cuối?
Chúng tôi đã nghĩ về một vài lựa chọn ở đây:
Sao chép toàn bộ phần mềm và cũng lưu trữ phần mềm đó trong AWS ap-southeast-2
Lợi ích: hiệu suất tuyệt vời, dễ cài đặt, CI/CD sẽ cho phép triển khai đồng thời cùng một mã ở EU và AU.
Hạn chế: chúng tôi phải duy trì và trả tiền cho hai bộ cơ sở hạ tầng giống hệt nhau, dữ liệu không thể chia sẻ dễ dàng, rất nhiều sự trùng lặp về mọi mặt.
Chỉ di chuyển các phiên bản tính toán sang AWS ap-southeast-2
Không, sẽ không hoạt động vì cơ sở dữ liệu hoặc truy vấn redis sẽ bị ảnh hưởng nhiều hơn bởi thời gian khứ hồi.
Có một bản sao chỉ đọc trong AWS ap-southeast-2 và ghi trong eu-central-1
Tốt hơn là tùy chọn 2, nhưng thêm nhiều độ phức tạp trong mã cộng với số lần ghi thường không phải là ít.
Thiết lập bộ cân bằng tải trong AWS ap-southeast-2 và kết nối ngang hàng với các VPC
Ý tưởng: người dùng kết nối với điểm cuối AU và lưu lượng truy cập sẽ đi qua kết nối mạnh mẽ với các phiên bản EU. Tuy nhiên, điều này rõ ràng sẽ không làm giảm khoảng cách và chúng tôi không chắc chắn về khả năng cải thiện (nếu có?)
Có ai đã gặp phải vấn đề tương tự và sẵn sàng chia sẻ một số thông tin chi tiết không?
Cập nhật: có vẻ như chỉ yêu cầu HTTPS đầu tiên có vẻ rất chậm.
Trong khi tìm hiểu các tùy chọn AWS Load Balancer, tôi cũng nhận thấy rằng Công cụ tăng tốc toàn cầu AWS có thể hữu ích, vì vậy chúng tôi đã làm một số thử nghiệm.
Từ hệ thống địa phương (tại EU):
curl -w "dns_resolution: %{time_namelookup}, tcp_founder: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas.example .com/ping" "https://saas.example.com/ping"
dns_độ phân giải: 0,019074, tcp_ thành lập: 0,041330, ssl_handshake_done: 0,081763, TTFB: 0,103270
dns_độ phân giải: 0,000071, tcp_ thành lập: 0,000075, ssl_handshake_done: 0,000075, TTFB: 0,017285
Từ AU (ví dụ EC2):
curl -w "dns_resolution: %{time_namelookup}, tcp_founder: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas.example .com/ping" "https://saas.example.com/ping"
dns_độ phân giải: 0,004180, tcp_ thành lập: 0,288959, ssl_handshake_done: 0,867298, TTFB: 1,161823
dns_độ phân giải: 0,000030, tcp_ thành lập: 0,000032, ssl_handshake_done: 0,000033, TTFB: 0,296621
Từ AU đến AWS Global Accelerator (ví dụ EC2):
curl -w "dns_resolution: %{time_namelookup}, tcp_founder: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas-with -global-accelerator.example.com/ping" "https://saas-with-global-accelerator.example.com/ping"
dns_độ phân giải: 0,004176, tcp_ thành lập: 0,004913, ssl_handshake_done: 0,869347, TTFB: 1,163484
dns_độ phân giải: 0,000025, tcp_ thành lập: 0,000027, ssl_handshake_done: 0,000028, TTFB: 0,294524
Tóm lại: Có vẻ như quá trình bắt tay TLS đang gây ra độ trễ ban đầu lớn nhất. Tuy nhiên, nếu nó có thể được sử dụng lại, thời gian bổ sung cho AU đến EU dường như thực sự "chỉ" ~277 mili giây (0,294524 giây - 0,017285 giây) cho Thời gian đến Byte đầu tiên.
Lời chào hỏi!
