Nếu tải một nhân vật mà phải truy vấn riêng lẻ vài chục lần, thì vài chục nghìn người đăng nhập cùng lúc sẽ thành hàng triệu query.
Vì sao Khi tải nhân vật, truy vấn vật phẩm, skill, nhiệm vụ riêng từng thứ một → Dẫn đến Ngay sau bảo trì, đăng nhập đồng thời làm số query tăng vọt → Trên màn hình Đăng nhập kẹt loading, việc lưu của người đang chơi cũng bị dồn lại
Phụ trách chính Phát triển server (Đội phát triển game) · Phối hợp Hạ tầng DB (Đội hạ tầng)
Việc cần làm (Đội phát triển game)
Gộp thành một lần truy vấn, hàng chờ đăng nhập, cache, kiểm tra số truy vấn do lazy loading của ORM sinh ra.
Việc cần làm (Đội hạ tầng)
Lập bảng xếp hạng các query bị gọi nhiều nhất và chia sẻ, giám sát số query và số kết nối trong khung giờ đăng nhập ngay sau bảo trì.
Trên đồ thị
Tăng vọt ngay sau đăng nhập hoặc bảo trì · Số query mỗi giây của DB, số lượt đăng nhập
Chỗ cần xem
Đặt chồng số lượt đăng nhập ngay sau bảo trì với số query mỗi giây của DB (MySQL: mức tăng của Questions) và tính số query cho mỗi lượt đăng nhập. Lấy các query bị gọi nhiều nhất từ COUNT_STAR trong events_statements_summary_by_digest của MySQL, calls trong pg_stat_statements của PostgreSQL
Đúng nếu
mỗi lượt đăng nhập tốn vài chục query, và các query đứng đầu là những query ngắn cùng dạng, truy vấn theo một ID nhân vật. Nếu số query mỗi lượt đăng nhập tăng sau bản cập nhật thì bản cập nhật đó là điểm xuất phát
Loại trừ nếu
số query mỗi lượt đăng nhập ít mà từng query đều chậm → cache lạnh (db-cold-cache) hoặc index (db-no-index)
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Tìm hiểu thêm
Lazy loading của ORM (thư viện tự sinh truy vấn DB thay cho lập trình viên) tạo ra kiểu truy vấn này mà chính lập trình viên cũng không hay biết. Trên server dev chỉ có vài nhân vật nên không lộ ra, đến khi đăng nhập đồng thời trên môi trường live mới bộc lộ lần đầu.
Nguồn
Efficient Querying.NET Lazy loading của ORM gửi thêm một query cho mỗi phần tử, sinh ra vấn đề N+1 làm hiệu năng giảm mạnh; khuyến nghị nạp gộp một lần (eager loading)