It really doesn't matter it a second instance kicks in to process your user-facing requests. If your max_idle_instances is set to 1, then you're only paying for one idle instance at any given time. Remember that "max_idle_instances=1" doesn't mean "max_instances=1". I do agree your concerns, and I'm curious to know too, why the scheduler is starting a second instance, even though min_latency is set to 15 seconds. Nevertheless, you should still be able to stay under the free quota of 28 instance hours. The periodic image uploads will take up 24 instance hours, and any extra processing time that those uploads require, and any user-facing requests require will most likely fit into the remaining 4 instance hours. Any idle time for the second (or third, or fourth) instance will not be billed to you (only the processing time of the extra instances will be billed). This was in fact the motivation behind increasing the free instance hours from 24 to 28.
On Tue, Sep 13, 2011 at 4:30 PM, dloomer <dloo...@gmail.com> wrote: > I have a simple webcam app used by a maximum of maybe 3 people at any time, > which also handles requests from a batch process initiated from my house > which uploads a new image to my app every 15 seconds via HTTP call to my > app's frontend. My goal is to get the app running on just a single frontend > instance at all times, making this as close to a free app as possible, but > this is proving much more difficult than I thought it would. > > When no one is connected to my app, all the uploads go to a single > instance. All the requests complete with around 200ms latency. > > However, as soon as one user accesses the main page of my app, a new > instance spins up. *This in spite of the fact that a browser request to > my app typically completes in well under a second, and Min Pending Latency > is set to 15 seconds.* > > What is it that would make the scheduler think that one instance won't > handle both sets of requests, when the Min Pending Latency is set so high > and none of the requests come anywhere near this threshold? One theory: I > remember reading on these forums a while back, under a topic regarding > keeping an instance "always on", that the scheduler has strategies to > prevent you from keeping an instance "always on" by constantly pinging it. > My 15-second periodic upload is similar to a ping in this sense. I don't > intend anything nefarious, but the scheduler wouldn't know this, and maybe > is just trying to close a loophole that someone else could exploit. > > I'd use a backend to handle the image uploads, but I need it running 24 > hours and a 24-hour backend isn't free. > > I don't think this would work as a "free" app by Google's billing terms > (which I believe would restrict me to a single frontend by default), as it's > likely I'll go over quota on datastore operations farily regularly. > > Any ideas on how I can keep my app as cheap as possible without sacrificing > functionality? > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine/-/-OicXg1wyQIJ. > To post to this group, send email to google-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- 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 google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
