The number of instances that App Engine makes available to your application depends on if you keep your average request time under 1000ms for user-facing requests.
Ikai Lan (I believe) said that taskqueue and cron job requests do not count against this boundary. Ikai also said that this boundary was in place because longer requests were bad for the ecosystem. Since taskqueue and cron job requests do not count against this boundary, in order for them to not be bad for the ecosystem, I'm guessing that they are served from a different set of servers than user-facing requests are. We (appid: steprep) have a number of external machines that also hit our urls. While we make every effort to keep user-facing requests quick and responsive, we often use many seconds serving the requests that are built for external machines (by design). It has only just struck me this morning that this could be having a bad (perhaps dramatic) impact on our overall scaleability. First off, is it true that cron and taskqueue items are served on a different set of servers? If so, is there any way to designate that a particular url is being requested by a machine and can be routed to this alternate set (of presumably slower) servers (e.g., a request header)? If I'm way off on all of this, and if taskqueue and cron jobs are served from the same set of servers, I'm not sure how the "bad for the ecosystem" argument holds, and perhaps Google should revisit this 1000ms boundary condition altogether. -- 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.
