rate limits and performance talk


Rate Limitsand API Best Practices

<SPEAKER>, Google, Inc.

API SERVER


● API Best Practices

● What are Rate Limits?

● How to handle Rate Limits

Agenda


Best PracticesSome simple things to speed up your applications


Batch Operations Together AdWords API Workshops – All rights reserved

● 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


● 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

Group Operations by Target


● 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.

Only Update What you Need to


● 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

A Couple of Other Ideas …


Defining Rate Limits

AdWords API Workshops – All rights reserved Defining Rate Limits

● Are not fixed

● Vary on server load

● Vary per feature area

● Will change over time

● Different per AdWords service

Rate Limits

AdWords API Workshops – All rights reserved Defining Rate Limits

● 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

Rate Limit Errors


How to Handle Rate LimitsCareful coding...


Basic Example

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);

}

}

Java

How to handle Rate Limits


● 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

Basic Example - Explained


● 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

Important Points About the Basic 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

A More Advanced Solution


● 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...

Message Queues (cont’d)


Consumers


1. Single Queue

Queue

Producer

Producer

Producer

ConsumersThrottling

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

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

X Error

Consumers

Logging


● 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

First Approach - Pros & Cons


Producers

Producers

Producers

Producers


2. Single Queue with Selectors

Queue

Producers

Producers

Producers

Producers

Producers

Producers

Producers

Producers

Consumer

Consumer

Consumer

Consumer

Throttling

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

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

XXXX Error


● 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

Second Approach - Pros & Cons

AdWords API Workshops – All rights reserved How to handle Rate Limits

3. Multiple Queues

Producers

Producers

Producers

Producers

Queues

Producers

Producers

Producers

Producers

Producers

Producers

Producers

Producers

Consumer

Consumer

Consumer

Consumer

Throttling

XXXX

Error

ProducersExecutorsExecutorsExecutors

Throttling

Logging

Producers just spawn a lot of tasks

Consumers just group the tasks

Executors do the request


● 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

Third Approach - Pros & Cons


● 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...

Message Queues - Takeaways


ResourcesAPI Best Practices - https://developers.google.com/adwords/api/docs/guides/bestpractices

ActiveMQ - http://activemq.apache.org/RabbitMQ - http://www.rabbitmq.com/

https://developers.google.com/adwords/api/docs/guides/bestpractices



http://activemq.apache.org/

http://www.rabbitmq.com/


Questions?Thank you!

rate limits and performance talk

Technology