Hmmm, that poses a different issue for us. Our application does _substantially_ more long-running, taskqueue- based requests relative to user-facing requests. Indeed, our primary user interaction is via the reports that we compile and email to them.
This just sounds like a generally bad situation for us. Any thoughts? On Sep 16, 6:44 am, "Nick Johnson (Google)" <[email protected]> wrote: > Hi Jason, > > The same appservers are used to serve user-facing and offline traffic. The > volume of user-facing traffic (that is below the latency threshold) you > serve determines how many appservers we provision for your application, > which in turn affects the capacity available for running offline (task queue > and cron) tasks. > > -Nick Johnson > > > > > > On Thu, Sep 16, 2010 at 1:41 PM, Jason C <[email protected]> wrote: > > 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]<google-appengine%2Bunsubscrib > > [email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-appengine?hl=en. > > -- > Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: > Registered in Dublin, Ireland, Registration Number: 368047 > Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: > 368047 -- 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.
