Giới hạn và hạn mức

Các hạn mức và giới hạn giúp bảo vệ cơ sở hạ tầng của Google khỏi một quy trình tự động sử dụng Reports API theo cách không phù hợp. Việc gửi quá nhiều yêu cầu từ một API có thể là do lỗi chính tả không gây hại hoặc do một hệ thống được thiết kế không hiệu quả, dẫn đến các lệnh gọi API không cần thiết. Bất kể nguyên nhân là gì, việc chặn lưu lượng truy cập từ một nguồn cụ thể khi lưu lượng truy cập đạt đến một mức nhất định là cần thiết để đảm bảo hệ thống Google Workspace hoạt động ổn định. Quy định này đảm bảo rằng hành động của một nhà phát triển không thể ảnh hưởng tiêu cực đến cộng đồng lớn hơn.

Trong trường hợp không mong muốn là yêu cầu API của bạn không thành công, bạn sẽ nhận được phản hồi mã trạng thái HTTP. Mã trạng thái 403 có thông tin lỗi về dữ liệu đầu vào không chính xác và mã trạng thái HTTP 503 có thông tin lỗi cho biết bạn đã vượt quá hạn mức API nào. Những phản hồi này cho phép ứng dụng tuỳ chỉnh của bạn phát hiện các lỗi này và thực hiện hành động thích hợp.

Nếu yêu cầu của bạn cần được hoàn tất trong một khoảng thời gian cố định, hãy gửi các yêu cầu song song hoặc sử dụng nhiều luồng trong ứng dụng Java hoặc C# của bạn. Ví dụ về các yêu cầu song song là yêu cầu các lô nhỏ email từ nhiều người dùng thay vì thêm hoặc xoá nhiều email của một người dùng cùng một lúc. Trong trường hợp có nhiều luồng, hãy thử bắt đầu với 10 luồng, mỗi luồng một email người dùng. Xin lưu ý rằng đề xuất về luồng có những điểm hạn chế và không hữu ích cho mọi trường hợp sử dụng API. Nếu số lượng yêu cầu quá cao, lỗi hạn mức sẽ xảy ra.

Đối với tất cả các lỗi dựa trên thời gian (tối đa N thứ trong N giây cho mỗi luồng), đặc biệt là lỗi mã trạng thái 503, bạn nên để mã của mình bắt ngoại lệ và sử dụng thuật toán thời gian chờ luỹ tiến, đợi một khoảng thời gian ngắn trước khi thử lại lệnh gọi không thành công. Ví dụ về Reports API cho một luồng là đợi 5 giây rồi thử lại lệnh gọi không thành công. Nếu yêu cầu thành công, hãy lặp lại mẫu này cho các luồng khác. Nếu yêu cầu thứ hai không thành công, ứng dụng của bạn nên giảm tần suất yêu cầu cho đến khi một lệnh gọi thành công. Ví dụ: tăng độ trễ ban đầu từ 5 giây lên 10 giây và thử lại cuộc gọi không thành công. Ngoài ra, hãy quyết định giới hạn số lần thử lại. Ví dụ: hãy thử lại một yêu cầu từ 5 đến 7 lần với các khoảng thời gian trễ khác nhau trước khi ứng dụng của bạn trả về lỗi cho người dùng.

Giới hạn

Danh mục giới hạn API Giới hạn
Báo cáo tỷ lệ QPS và QPD API này giới hạn số lượng yêu cầu cho dự án Google Cloud của bạn. Giá trị mặc định được đặt trong Google Cloud Console là 2.400 truy vấn mỗi phút cho mỗi người dùng cho mỗi dự án trên Google Cloud. Bạn có thể tăng hạn mức này trên trang Hạn mức API Admin SDK của dự án trên Google Cloud.

Nếu vượt quá các giới hạn này, máy chủ sẽ trả về mã trạng thái HTTP 503. Sử dụng thuật toán thời gian đợi luỹ thừa khi thử lại các yêu cầu.

Các giới hạn khác đối với activities.list activities.list API có thêm giới hạn là 250 truy vấn bộ lọc mỗi phút (15.000 truy vấn bộ lọc mỗi giờ). Truy vấn bộ lọc là một yêu cầu API chứa ít nhất một trong các tham số truy vấn sau:
  • userKey
  • actorIpAddress
  • eventName
  • filters
  • orgUnitID
  • groupIdFilter
Danh mục hạn mức API Hạn mức
maxResults Số lượng bản ghi được liệt kê trong mỗi trang của phản hồi API là từ 0 đến 1000 bản ghi. Giá trị mặc định là 1.000 bản ghi.

Các loại giới hạn khác

Các loại giới hạn khác Giới hạn và nguyên tắc
Định dạng dữ liệu, mặc định Định dạng dữ liệu mặc định là JSON. API này cũng hỗ trợ định dạng Atom.
Yêu cầu trái phép Google không cho phép các yêu cầu trái phép đối với API. Một yêu cầu được coi là trái phép nếu không có mã uỷ quyền nào được cung cấp. Để biết thêm thông tin, hãy xem phần Uỷ quyền yêu cầu.
Thông báo cảnh báo
  • Không có dữ liệu: Dữ liệu cho ứng dụng này và cho ngày này không có và sẽ không có trong tương lai.
  • Có dữ liệu một phần: Dữ liệu cho ứng dụng này và cho ngày này có thể sẽ có trong tương lai.
Để biết cú pháp cảnh báo của Reports API, hãy xem Tài liệu tham khảo API cho khách hàng và cho người dùng.

Các phương pháp hay nhất cho activities.list

Phương thức activities.list dự kiến sẽ được dùng cho các cuộc điều tra kiểm tra. Để đạt hiệu suất tốt nhất, yêu cầu của bạn nên bao gồm một phạm vi thời gian bằng cách sử dụng các tham số startTimeendTime. Phạm vi thời gian càng hẹp thì thời gian phản hồi càng nhanh hơn đáng kể. Phương thức này không dùng để truy xuất nhật ký kiểm tra với số lượng lớn. Nếu bạn thường xuyên sử dụng hết hạn mức yêu cầu lọc activities.list, hãy cân nhắc những lựa chọn sau:

  • Thiết lập xuất nhật ký Google Workspace sang BigQuery và sử dụng API truy vấn mạnh mẽ của BigQuery để truy xuất và phân tích dữ liệu bạn cần mà không gặp phải bất kỳ hạn chế nào về hạn mức API.
  • Sử dụng các yêu cầu không có bộ lọc với phạm vi thời gian và thực hiện lọc phía máy khách (tức là thực hiện logic lọc trong ứng dụng của bạn), thay vì sử dụng các yêu cầu có bộ lọc. Điều này cho phép bạn vượt quá hạn mức 250 cụm từ tìm kiếm bộ lọc mỗi phút,nhưng bạn vẫn phải tuân theo hạn mức 2.400 cụm từ tìm kiếm mỗi phút cho mỗi người dùng cho mỗi dự án trên Google Cloud.