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.
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.
Agent versions
You should always use agent versions for your production traffic. See Versions and environments for details.
Session client reuse
You can improve the performance of your application's detect intent API calls
by reusing a SessionsClient
client library 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 be throttled. 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
, ordelete
requests, use thebatchUpdate
orbatchDelete
methods. - Instead of sending many
Intents
create
,patch
, ordelete
requests, use thebatchUpdate
orbatchDelete
methods.
API error retries
When calling API methods, you may receive error responses. There are some errors which should be retried, because they are often due to transient issues. There are two types of errors:
- Cloud API errors.
- Errors sent from your webhook service.
In addition, you should implement an exponential backoff for retries. This allows your system to find an acceptable rate while the API service is under heavy load.
Cloud API errors
If you are using a Google supplied client library, Cloud API error retries with exponential backoff are implemented for you.
If you have implemented your own client library using REST or gRPC, you must implement retries for your client. For information on the errors that you should or should not retry, see API Improvement Proposals: Automatic retry configuration.
Webhook errors
If your API call triggers a webhook call,
your webhook may return an error.
Even if you are using a Google supplied client library,
webhook errors will not be retried automatically.
Your code should retry 503 Service Unavailable
errors received from your webhook.
See the
webhook service
documentation for information on the types of webhook errors
and how to check for them.
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 Dialogflow service. The service is not designed to handle abrupt bursts of load, which are rarely experienced with real traffic. It takes time for the service 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. |