Best practices

This document lists best practices for using Dialogflow. These guidelines are designed for greater efficiency and accuracy as well as optimal response times from the service.

Section	Summary
Agent design	Improve agent quality and performance.
Session client reuse	Improve performance of detect intent API calls.
Batch updates to agent	Prefer batch agent updates to many individual updates.
API error retries	When to retry calls against the API.
Load testing	Advice for load testing your agent.

Agent design

Your agent design can greatly impact the quality and performance of your agent. See the Agent design guide for best practices focused on agent design.

Session client reuse

You can improve the performance of your application's detect intent API calls by reusing a client library session client instance for multiple requests.

For more information on this, see the Best Practices with Client Libraries page.

Batch updates to agent

If you are sending many individual agent update API requests over a short period of time, your requests may time out. These design-time API methods are not implemented to handle high update rates for a single agent.

Some data types have batch methods for this purpose:

• Instead of sending many EntityTypes create, patch, or delete requests, use the batchUpdate or batchDelete methods.
• Instead of sending many Intents create, patch, or delete requests, use the batchUpdate or batchDelete methods.

API error retries

When calling API methods, you may receive errors. These errors are described in the Cloud APIs error documentation.

If you are using a Google supplied client library, retries are implemented for you. If you have implemented your own client library using REST or gRPC, you must implement retries for your client.

Some errors indicate a problem with the request, and you should not retry the request. For example, INVALID_ARGUMENT (HTTP mapping: 400 Bad Request) should not be retried. This error is typically caused by a bug in your system.

There are some errors which should be retried, because they are often due to transient issues. You should retry requests for the following errors:

Error code	HTTP mapping
DEADLINE_EXCEEDED	504 Gateway Timeout
UNAVAILABLE	503 Service Unavailable

When retrying requests, you should also implement an exponential backoff. This allows your system to find an acceptable rate while the API service is under heavy load.

Load testing

It is a best practice to execute load testing for your system before you release code to production. Consider these points before implementing your load tests:

Summary	Details
Ramp up load.	Your load test must ramp up the load applied to the API. The API is not designed to handle abrupt bursts of load, which are rarely experienced with real traffic. It takes time for the API to adjust to load demands, so ramp up the request rate slowly, until your test achieves the desired load.
API calls are charged.	You will be charged for API calls during a test, and the calls will be limited by project quota.
Use test doubles.	You may not need to call the API during your load test. If the purpose of your load test is to determine how your system handles load, it is often best to use a test double in place of actual calls to the API. Your test double can simulate the behavior of the API under load.
Use retries.	Your load test must perform retries with a backoff.