Rate limits and performance Talk

API SERVER

Rate Limits
and API Best Practices

<SPEAKER>, Google, Inc.


Agenda
● API Best Practices
● What are Rate Limits?
● How to handle Rate Limits


Best Practices
Some simple things to speed up your applications


Batch Operations Together


● Requests to the API have certain costs
● Network transfer, serialisation, auth, etc.

● Batching operations into a single request reduces these
● mutate methods accept arrays of operations
● MutateJobService for batching


Group Operations by Target
● Multiple operations on the same AdGroup / Campaign
are faster
● Subsequent edits to same AdGroup or Campaign can
cause CONCURRENT_MODIFICATION errors
● Backend systems can take time to do their work
● Try to do all edits on AdGroups/Campaigns at once


Only Update What you Need to
● Updating an object?
● Only send the values that will change!
● Sending in all the other values wastes
time
●

The system still validates them, stores to DB, etc.


A Couple of Other Ideas …
● Compress your requests / response
with gzip
● Make sure User-Agent: has “gzip”
● Accept-Encoding: lists gzip

● Use partial failure feature
● Tells API to serialise those ops that
succeeded
● Returns list of those that failed

Defining Rate Limits


Rate Limits
● Are not fixed
● Vary on server load
● Vary per feature area
● Will change over time
● Different per AdWords service



Rate Limit Errors
● RATE_EXCEEDED
○ at least wait retryAfterSeconds seconds

● CONCURRENT_MODIFICATIONS
○ Exponential backoff, few retries only

● UNEXPECTED_INTERNAL_API_ERROR
○ Exponential back off, few retries only
○ Report the issue to your CSR or forum


How to Handle Rate Limits
Careful coding...


Basic Example
Java

ApiError[] errorArray = apiException.getErrors();
for (ApiError apiError : errorArray) {
if (apiError instanceof RateExceededError) {
int seconds = ((RateExceededError) apiError)
.getRetryAfterSeconds();
// wait the amount of seconds the server asked
Thread.sleep(seconds * 1000);
}
}

How to handle Rate Limits

Basic Example - Explained
● Any request can generate a RateExceededError
● Handling these errors is very important
● Wait and retry is the best strategy in
this case
● Even more important when
doing multiple requests


Important Points About the Basic Solution
● Synchronous solution to the problem
● Blocks the thread until it succeeds, or fails completely
● No control over request rate speed
● Very difficult to group operations


A More Advanced Solution
● Message Queues
● The perfect solution to distribute load and do
throttling
● Very good out of the box solutions available
●

ActiveMQ, RabbitMQ, … etc.

● A lot of tools / client libraries to handle
comms layer


Message Queues (cont’d)
● More control over the rates and limits
● Better break down into specialized modules
● Let’s take a look to three possible approaches to the
problem...


1. Single Queue
Producer

Producers will create tasks to be
executed using the API, and add
them to the queue

Producer

Consumers
Consumers
Consumers

X

Queue

Throttling

Producer

Logging

Error

Consumers will retrieve the messages/tasks
from the queue with a controlled rate limit


First Approach - Pros & Cons
● Pros:
● Very easy to implement
● Only one control point to change rate speed
● Easy to handle errors

● Cons:
●
●
●
●

Only one control point to change rate speed
Hard to group operations
Tasks can take too long to be executed
Not all MQs deal with message priority


2. Single Queue with Selectors
Producers
Producers

Producers will create specific tasks
to be executed, and add them to
the queue with a specific header

Producers
Producers

Each specific consumer can group
the operations, and execute within
your own rate limit using selectors
X
X
X
X

Producers
Producers

Queue

Throttling

Producers
Producers

Producers
Consumer


Producers
Consumer
Producers
Consumer
Producers
Consumer

Error


Second Approach - Pros & Cons
● Pros:
● Group operations by type
● Some control over throttling depending on type
● More efficient - better parallel access to the API

● Cons:
●
●
●
●

Only one queue - difficult to administer
No main control on how fast the API is called
Managing all the pieces can be difficult
Operation logging might be complicated


3. Multiple Queues
Executors do the request

Producers
Consumer

Producers
Producers

Producers
Consumer

Throttling

Producers
Producers

Producers
Producers
Producers
Producers

Producers
Consumer
Producers
Executors
Executors
Executors

Producers
Consumer
Queues

Consumers just group the tasks
Error

Logging

X
X
X
X

Producers just spawn
a lot of tasks

Throttling



Third Approach - Pros & Cons
● Pros:
●
●
●
●
●
●

Total control over rate limits
Very robust - very easy to add new parts
Complete picture on what is happening with the queues
Easy to scale based on demand
If done properly, easy to do maintenance!
Super efficient - Parallel grouping; Parallel access to the API

● Cons:
● Hard to implement properly - experience required


Message Queues - Takeaways
● Complexity of your platform dictates the best solution
● You can combine parts of other solutions!
● It is a complex subject, but will save you in the long run
● Invest a lot in monitoring. A lot!
● There is no silver bullet...


Resources
API Best Practices - https://developers.google.
com/adwords/api/docs/guides/bestpractices
ActiveMQ - http://activemq.apache.org/
RabbitMQ - http://www.rabbitmq.com/

Questions?
Thank you!


Rate limits and performance Talk

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

Similar to Rate limits and performance Talk

Similar to Rate limits and performance Talk (20)

More from marcwan

More from marcwan (20)

Recently uploaded

Recently uploaded (20)

Rate limits and performance Talk