This is great. We just turned on reserved instances for http://gri.pe (select "always on" in the billing section). It costs $9/month to keep three instances warm all the time. That's peanuts compared to saving the 10s warmup time if your traffic drops off for a minute.
Another huge item: up to 10 minutes of background processing on a single task queue callback:
No more 30-second limit for background work - With this release,
we’ve significantly raised this limit for offline requests from
Task Queue and Cron: you can now run for up to 10 minutes without
interruption.
Make sure you turn on the new warmup handlers for your applications too. With this, AppEngine will deliver a request to /_ah/warmup and let it complete before serving traffic from a new instance.
Can someone explain this "always on" in more detail? I don't have much experience with Google App Engine, does this mean apps not used frequently have a startup time? So, if noone accessed the site in the last few minutes, the first user accessing has to wait some time for use?
Exactly right. Especially with larger apps, the "first" user often sees some latency while the app is loaded into memory, static data structures are re-created, etc. The always on feature should keep this from happening.
Perhaps I'm being naive here, but doesn't an uptime-service like Pingdom do the job? They basically ping the site every 5 minutes which should keep the instance alive.
This release solves almost all problems we had with App Engine. Users now don't have to wait for an instance to start, so the site will always be fast. Also, DeadlineExceededError now can't lead to mysteriously broken instances, anymore (thanks Guido!). And with the Channel API we can build real-time collaborative apps.
Now we only need SSL support and here we come, blasting everyone away who wastes time on maintaining his own servers. :P Well, at least until the next feature is needed, but not available, so let's hope this won't be the case. ;)
Also, DeadlineExceededError now can't lead to mysteriously broken instances
Note that the increase in the deadline to 10 minutes only affects background tasks (ie, the Task Queue and Cron jobs). It's important, but won't fix those DeadlineExceededError on a user-facing page errors on it's own.
What the parent is referring to is that when a Python process gets the DeadlineExceededError, it will now be recycled. Previously it would be re-used, and this would break things if the error happened in the middle of a module import (because the module would not be re-imported). Django was especially vulnerable to this.
The pricing power this reveals Google to have is fascinating. On Heroku, which runs on top of EC2, 3 dynos running all the time cost $72 a month. Google is charging $9 for what seems to be the same thing. Is Heroku really charging 8 times as much, or are their dynos not directly comparable to Google's app instances?
Unless you have a very CPU-heavy application it's unlikely AppEngine will ever cost more than Heroku. 8 times at much seems a lot, but 5 times as much wouldn't surprise me.
Heroku is selling a lot more than Google. With Heroku there are few constraints on your app other than Ruby. You can do very traditional web development (SQL among other things) and there are a lot of conveniences available for you. You should be able to build your app faster and launch 1 instance for $0, and then pay Heroku when it needs to scale. Google will force you to build in a more cumbersome manner, but it will scale much better so you won't have to pay them as much. You are always going to pay more for something like Heroku that is very much optimizing developer time.
I think Heroku's pricing contains both the RAM and CPU cost for the instances. The Google price only includes the RAM cost of the servers, the CPU is still charged per request.
Thanks to all three of you for the answers-I didn't realize AppEngine's pricing model unbundled warmed-up app instances resident in RAM from CPU time and bandwidth, which makes their offering not directly comparable to Heroku.
Their implementation of the channel is interesting compared to say, socket.io. Its essentially a one-way-only pipe where data can flow out of the server, to a client. The server only sees it as a pipe, and never gets any data back through it, not even connects or disconnects.
Any server-bound data must be sent through a REST interface, and the corresponding state retrieved through memcache or a DB request. To track connections, the client must periodically send notifications to the server to keep it alive:
"If the application needs to keep track of which clients are connected, one solution is to set the socket’s onopen property to call a function designed to send a POST message to the server at some regular interval in order to notify the server of the client's state."
I hate the www thing too. The explanation is that you cannot have a cname on a root domain. They coud get around e problem by just hosting dns for you themselves.
The other issue is that you end up having t have yet another service to redirect dom.ain to www.dom.ain as well. Sometimes dns providers will do this, but not always. (Dotster doesn't do the right thing, for example.)
The general impression, as I've understood it so far, is that App Engine has its limitations, but Google makes you well aware of them, so adapt to them and don't get frustrated or surprised by them two months into development, or host your service somewhere else like AWS.
I just turned on the "always on" feature for http://www.quickbrownfrog.com. Worth spending $9/month on. I imagine this will lead to lots of instant cash for Google from frustrated developers.
App Engine is great if you design your app within its limitation. It's just a different architecture to work with.
I haven't found the cold start or 30-second limit a problem yet. I have a cron job running periodically hitting the app to schedule tasks, that seems to always keep an instance running. The tasks were designed to do small things and finished in a short time. That actually helps to spread the tasks to more machines.
It does seem App Engine is running faster in the last week or so; it was kind of slow before. The new Play Back feature in my app http://www.previouslook.com actually works without much hiccup now.
Is i possible to try it out first, before commiting on the payment details? Like an index, with only 100 docs etc. I just want to get a feel for it would all tie in.
Channel API: “There is no concept of “presence” for clients connected to a channel. This means the application cannot receive a call when a client connects to or disconnects from a channel.”
Sigh... this reduces the awesomeness quite a bit :|
The developer who uploaded an app version can download that
version's code using the appcfg.py download_app command.
This feature can be disabled on a per application basis in
the admin console, under the 'Permissions' tab. Once
disabled, code download for the application CANNOT be re-
enabled.
I just created a new throwaway site to confirm this. It seems you can't download your previously deployed apps, but only applications uploaded by v1.4.0.
Yes! I've looked longingly at App Engine several times in the past but the 30 second limit was always a big fail. To me it's always been what separated App Engine from a platform for serving AdWords to a platform I could put a business intelligence app on.
If I remember correctly they had a cap of 30 seconds even for processing requests. Has this cap also been removed or it is only the cap on the task api that has been removed?
Another huge item: up to 10 minutes of background processing on a single task queue callback:
Make sure you turn on the new warmup handlers for your applications too. With this, AppEngine will deliver a request to /_ah/warmup and let it complete before serving traffic from a new instance.XML:
YAML: