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.

The initial request made by an instance of a session client performs authentication, authorization, and access token generation. This processing can take multiple seconds. For further calls, the session client reuses the same access token for as long as it is valid (typically one hour). Once it expires, the session client refreshes the access token automatically, which can take multiple seconds to perform.

For optimal performance, you should reuse the same session client instance for all requests made by your application, and allow the client to refresh the access token as needed.

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.