Với kiến trúc mà thread không làm được việc gì khác trong lúc chờ một socket, người chơi càng đông thì cả hệ thống càng chậm.
Vì sao Mỗi kết nối tự chờ đọc và ghi của riêng nó → Dẫn đến Độ trễ của một kết nối lan sang các kết nối khác trên cùng thread → Trên màn hình Số người chơi đồng thời càng tăng, mọi người càng bị quay chậm và trễ thao tác
Phụ trách chính Phát triển server (Đội phát triển game)
Việc cần làm (Đội phát triển game)
Chuyển sang I/O bất đồng bộ dựa trên epoll, IOCP hoặc io_uring.
Trên đồ thị
Tăng theo số người và tải · Thời gian phản hồi, số thread
Chỗ cần xem
Số thread của server game và context switch tự nguyện theo từng thread (cswch/s, số lần dừng để chờ tài nguyên) qua pidstat -w -t, so với thời gian phản hồi khi số người chơi đồng thời tăng
Đúng nếu
số người chơi đồng thời càng tăng, thời gian phản hồi càng tăng vọt, và phần lớn thread (tăng theo số kết nối) chỉ có nhiều context switch tự nguyện mà gần như không dùng CPU (đang chờ socket)
Loại trừ nếu
thread dùng CPU liên tục mà không phải chờ → quá tải tính toán (“Vượt tick budget”)
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Nguồn
epoll(7) — Linux manual pageLinux man-pages Cơ chế thông báo sự kiện I/O mở rộng được để theo dõi nhiều fd cùng lúc
I/O Completion PortsMicrosoft Cách làm của Windows: xử lý nhiều I/O bất đồng bộ bằng thread pool tạo sẵn
pidstat(1) — Linux manual pagesysstat cswch/s trong -w: context switch tự nguyện (tác vụ tự dừng để chờ tài nguyên); -t hiển thị theo từng thread