What is the difference between appengine 5 and 11 repository timeout errors?

I am trying to speed up the Google App Engine request handler, which has a large PutMulti storage PutMulti (500 entities), breaking it into lots of objects and launching parallel goroutines to send smaller PutMulti calls (100 objects each).

Prior to this, I often received a datastore Call error 11: Deadline exceeded (timeout) from my PutMulti calls, which go to the deadline when I tested the handler in many concurrent requests. After parallelization, the handler accelerated, but I still sometimes got this error, as well as another error, API error 5 (datastore_v3: TIMEOUT): The datastore operation timed out, or the data was temporarily unavailable .

Is this error 5 due to competition in the data warehouse and what is the difference between errors 5 and 11?

+7
google-app-engine concurrency go google-cloud-datastore
source share
2 answers

The first error you see may just be a timeout in normal operation, the second is probably due to competition for the recording. More on this: Data Warehouse Error Handling https://cloud.google.com/appengine/articles/handling_datastore_errors

+1
source share

These errors come from two different places: the first, a call error, is a local error caused by a timeout in the RPC client. This indicates that the RPC completion timeout has completed. The default RPC timeout at google.golang.org/appengine is 60 seconds.

The second error comes from the service side. This error indicates that a timeout has occurred performing operations in the data warehouse. Some of these operations have timeouts much shorter than 60 seconds, and usually this may indicate competition.

Perhaps an easier way to understand the differences is that you will find that if you do one multi operation with a very large number of changes, you can easily start the first timeout. If you create a significant number of simultaneous operations against a single key or a small set of keys, you can easily invoke the latter. Since timeouts are common indicators of saturation of shared resources, of course, there are many ways and combinations to generate them. In general, you will want to repeat the operations as necessary, as well as perform the appropriate size operations and adjust the hotkey operations as best as possible to reduce the likelihood of competition problems. As others have suggested, python and java docs already have examples of this.

You might want to use https://godoc.org/google.golang.org/appengine#IsTimeoutError , and if you need to increase the timeout for the first class of errors, you may be able to adjust the deadline for the context, see the methods here : https://godoc.org/golang.org/x/net/context#WithDeadline Note: you cannot extend the deadline not exceeding the deadline for submitting a request, however, if you work in tasks or virtual machines, you can extend them until the deadlines.

+1
source share

All Articles