@Ugorji Shutting down an instance after 1 minute of inactivity would be bad for java apps which usually take 5+ seconds to start up. The scheduler will probably take into account a bunch of different variables in determining how long to leave an instance running.
On May 20, 11:52 am, Ugorji <[email protected]> wrote: > Hi Greg, > > Thanks for the detailed response. It removes a lot of the uncertainty, > allowing us focus on actual concerns. > > My main concerns now are: > - prohibitive cost of backend instance > - 15 minutes idle time cost for frontend instances > - details on what experimental entails, with respect to GO runtime > > *Prohibitive cost of backend instance* > Backend Instances seem ridiculously and prohibitively high ($115/month for a > resident 256MB/1.2GHz instance). Their prohibitive costs makes them very > unattractive for a lot of users who could leverage this functionality, > causing us to look elsewhere. > > In a way, it seems we're caught between a rock and a hard place. Backends > are an excellent way to do long-running CPU-intensive actions, allowing us > move away from the current practice of spawning chains of tasks which each > complete in a set time, or using a map-reduce operation. However, the > backends are so expensive that most people will not use them. Unfortunately, > the current practice of using frontend instances and tasks/map-reduce is now > expensive also because for each instance, we have to pay an extra 1/4 > instance hour tax beyond our usage. > > *15 minutes idle time cost for frontend instances* > For backends, the 1/4 hour may make sense, since backends are typically used > for long-running tasks. > > However, for frontends where requests should typically finish within a > second, and loading time can be within a second, the 1/4 hour tax seems > unfair. Since loading time and request time for frontends can be within a > second, it doesn't make sense to keep idle instances up for 15 minutes. > Something in the tune of 1 minute for instances beyond the first one is more > ideal (ie if u have one instance handling requests, keep the 15 minutes idle > time. For instances 2 and up, shut them down after 1 minute of inactivity). > > *details on what experimental entails, with respect to GO runtime* > The other question I had was with GO support. The current SDK > - does not support transactions, batch datastore operations, parallel > requests, etc > - depends on using the remote API to the python SDK which could limit the > ability to do some functionality (e.g. integrated testing framework, etc) > - has an API which sometimes feels like a proof-of-concept API, and not a > fully designed uniform API set > - Also, the Google Group for it seems like a ghost town, which suggests > either low interest or some level of disappointment in the current SDK set > > It looks really "experimental" unlike the Java SDK which was experimental > when released but was much more featureful and integrated. Can you define > what experimental means with respect to GO runtime: > - how long will it be supported for, in case Google decides to pull the plug > for lack of demand > - is there a roadmap for the features. -- 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.
