Stephen, Thanks for you input. Sorry about the thread length, but I've always been too verbose.
I'd not known exactly which number in that appstats line applied to the 1,000 ms throttling. Appreciate the input. Our latency (first number) on the new record put is around 850 ms for the put that had 585 ms api-cpu total. So I definitely now plan to make this change. The changes on the GAE side are really quite simple. We'll move the code from the handler function to the task queue module. I've already done that with some other function calls, and am very confident this will be easy and fast. On the client side, I've got to rip up a good bit anyway because we will not be leveraging Adobe Air's local datastore with the new product. So this is the right time to do it. As I noted, there are some very appealing parts to using the task queue, so overall I'm happy to do this. Example: some of the overhead related to the current new record "all-enclusive" handler function can be sent to low-priority queues. It may also prove very beneficial in the future that we have some ability to tune individual TQ resource availability. Thanks again, stevep On Nov 12, 8:45 am, Stephen Johnson <[email protected]> wrote: > I apologize if this has been asked and answered in this thread. I tried > looking through it but it is very long. From what I can tell you haven't > answered what your latency is for these requests and I believe that is very > important before you do all the work which is outlined below. From what I > understand throttling is affected by the latency time for the requests not > for CPU or API CPU usage. For instance you could have a request which takes > 2,000 MS API CPU but it's latency is 300MS. The first number in the logs > before the CPU MS and API CPU MS indicates the latency for the requests. You > say that you have a lot of custom indexes for these entities. My assumption > would be that these custom indexes would be updated by the datastore in > parallel and as such you could have a very high API CPU usage but your > latency could be very low. For example, looking at my log I have a request > which has numbers like this: > > 238ms 678cpu_ms 305api_cpu_msThe first number is the number after the 200 > return code and is the latency. It is almost a third less than the total for > CPU MS and falls (what I am presuming) safely within the recommended latency > times. At least this is the way I understand it. Also, if this has been > asked/answered below I apologize for repeating. > > Steve -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
