Dynamic Request Throttling

 

To help maximize uptime and request handling speed, PubChem web servers employ a dynamic, web-request throttling approach that enforces usage policies.  Importantly, during periods of excessive demand, these policies may be dynamically changed to maintain accessibility to all users.  Requests exceeding limits are rejected (HTTP 503 error).  If the user continuously exceeds the limit, they will be blocked for a period of time.

 

Therefore, the user should moderate the speed at which requests are sent to PubChem, according to the traffic status of PubChem and the extent to which the user is approaching limits.  This information is provided in specialized HTTP response headers accompanying all PUG-REST web requests.  For example, the HTTP response header contains a line similar to the following:

 

X-Throttling-Control: Request Count status: Green (0%), Request Time status: Green (0%), Service status: Green (20%)

 

The first two status indicators (Request Count and Time statuses) give information on your usage of the service in one of four states:

  1. Green - less than 50% of the permitted request limit has been used
  2. Yellow - between 50% and 75% of the request limit has been used
  3. Red - more than 75% of the request limit has been reached
  4. Black - the limit has been exceeded and requests are being blocked

The third indicator (Service status) shows the concurrent usage of the service in one of four states:

  1. Idle (Green) - Low concurrent usage being applied to the service at present
  2. Moderate (Yellow) - a moderate number of concurrent requests are being handled
  3. Busy (Red) - a significant number of concurrent requests are being handled
  4. Overloaded (Black) - an excessively high number of concurrent requests are being handled

 

It is important to note that there are many instances of PubChem services running in parallel. Each instance receives traffic from a load balancer, which distributes the requests across the system. Thus, when a stream of requests is sent to PubChem, the responses will be relative to the PubChem server instance handling the request. One server instance can become overloaded while others may not, depending on the overall nature of requests sent to that server. When providing many requests, one should moderate the speed requests are sent to according to the worst-case usage feedback received.  This will prevent uneven rejection of requests by PubChem services.
 

Was this information helpful?

The page cannot be found

The page you are looking for might have been removed, had its name changed, or is temporarily unavailable. Please make sure you spelled the page name correctly or use the search box.