There could be all kinds of things that cause random long periods of delay, depending on how the framework actually measures the time.
For example: 1) Virtualization scheduling -- if they use something like Xen, it may at times pre-empt your entire kernel image and take time out. 2) Garbage collection -- if the process keeps running, at some point it will have accumulated enough garbage that it may need to stop-and- collect. 3) Some driver or interrupt handler -- if the measurement is in "wallclock" time, then any mis-behavior on the kernel part (flushing buffers synchronously, a driver that poll-waits for some timeout, etc) will show up as "yours." Without knowing more how the duration is calculated, and what the execution environment is in the cluster, it's really hard to focus on only one possible cause. Especially if you can't even get kernel log outputs or syslog type data from the (virtual?) machine itself. Sincerely, jw On Dec 9, 3:14 pm, Greg <[EMAIL PROTECTED]> wrote: > Thanks to those who responded. My observation that the blips occur at > apparently random times during the handler run lead me to be a little > suspicious of the new interpreter theory - I only do fairly minor > "from xxx import yyy" imports in some of the sections that have > included blips. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
