Happy Holidays from the App Engine team - 1.4.0 SDK released(googleappengine.blogspot.com)

137 pointsby nikosdimopoulos16 tahun yang lalu54 comments

googleappengine.blogspot.com

Happy Holidays from the App Engine team - 1.4.0 SDK released

http://googleappengine.blogspot.com/2010/12/happy-holidays-from-app-engine-team-140.html

17 comments

mmastrac16 tahun yang lalu

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.

XML:

  <inbound-services>
   <service>warmup</service>
  </inbound-services>

YAML:

  inbound_services:
   - warmup

ludwigvan16 tahun yang lalu

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?

URSpider9416 tahun yang lalu

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.

herrherr16 tahun yang lalu

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.

mark_l_watson16 tahun yang lalu

Thanks for the price information - that is reasonable!

wkornewald16 tahun yang lalu

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. ;)

nl16 tahun yang lalu

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.

100k16 tahun yang lalu

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.

nl16 tahun yang lalu

Thanks - I wasn't aware of this (I do mostly Java stuff).

I'd imagine that the "warmup request" thing is especially useful for avoiding this.

100k16 tahun yang lalu

Indeed. Pre-warmup request, GAE would start sending requests to instances that were started but weren't fully loaded.

dreyfiz16 tahun yang lalu

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?

http://heroku.com/pricing#3-0

nl16 tahun yang lalu

$9 is for an always-on instance. It includes no CPU or bandwidth.

AppEngine pricing is quite complex. You need to look at the (very generous) free quotes first (http://code.google.com/appengine/docs/quotas.html#Resources), and then look at the pricing (http://code.google.com/appengine/docs/billing.html#Billable_...)

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.

gregwebs16 tahun yang lalu

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.

powera16 tahun yang lalu

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.

dreyfiz16 tahun yang lalu

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.

derekdahmer16 tahun yang lalu

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."

Kilimanjaro16 tahun yang lalu

This is like waking up and finding the bike you asked santa for next to the christmas tree.

Awesome!

* Now please let us use naked domains, I badly need it for my startup, I hate www to death.

marcc16 tahun yang lalu

"I badly need it for me startup" and "I hate www to death". Do you really need it that badly or do you really just want it?

I don't disagree, I would like to have it. Also SSL for my domain without having to use appspot.com. But I'd put SSL as a much higher priority.

Kilimanjaro16 tahun yang lalu

An url shortener would benefit more from a naked domain than from SSL.

* Not that I am working on one, just that you never know the poster intentions.

joshu16 tahun yang lalu

Oh god no more URL shorteners.

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.)

_stephan16 tahun yang lalu

Can maybe someone comment on the current reliability of GAE? What people write on this topic, for example in the comments on http://www.carlosble.com/?p=719&rewrite, sounds pretty scary. Apparently the status page at http://code.google.com/status/appengine doesn't reflect people's experiences.

Is it possible to work around the reported reliability issues? After all, what good is scalability without reliability?

kmfrk16 tahun yang lalu

This has been discussed a lot on HN lately - it was quite the meme for a while.

I did a quick !hn search for you[1] and saw these three popular submissions:

http://news.ycombinator.com/item?id=1934563

http://news.ycombinator.com/item?id=1931456

http://news.ycombinator.com/item?id=1927903

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.

[1]: http://searchyc.com/submissions/app+engine?page=1&sort=b...

herrherr16 tahun yang lalu

As a reference point:

Our service (getmetricmail.com) which is running on GAE had an uptime of 99.97% in November.

kaffeinecoma16 tahun yang lalu

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.

Now, if only we could have SSL...

rayboyd16 tahun yang lalu

Acording to the roadmap SSL should finally be here within the next 6 months. http://code.google.com/appengine/docs/roadmap.html

ww52016 tahun yang lalu

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.

joshu16 tahun yang lalu

i really wish they had a fulltext indexer available.

foobarbazoo16 tahun yang lalu

Hmm, I wonder if Google has tech to do that. Thinking...

fizx16 tahun yang lalu

Try websolr.com! Use coupon code SILVERTRIAL. If you hit me up at [email protected] after you sign up, I'll switch you to a comped account.

nl16 tahun yang lalu

Nice..

After writing a whole lot of scripts to do this myself, I'd been thinking this was a great market too.

Are you doing multiple Solr cores per JVM or does everyone get their own JVM?

sidmitra16 tahun yang lalu

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.

joshu16 tahun yang lalu

I'll check it out!

riobard16 tahun yang lalu

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 :|

bslatkin16 tahun yang lalu

We'll get there.

checker65916 tahun yang lalu

  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.

This sounds awesome too.

(source: http://code.google.com/p/googleappengine/wiki/SdkReleaseNote...)

ludwigvan16 tahun yang lalu

This sounds nice, but it responds by:

    Error 403: --- begin server output ---
    You do not have permission to download this app version.

even though I am the only developer. I wonder if this applies to downloading apps uploaded by this version.

ludwigvan16 tahun yang lalu

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.

checker65916 tahun yang lalu

This is not true (meaning, it worked for me). Are you sure you used a command something like this?

  $ appcfg.py download_app -A <app_id> <some_folder>

If it doesn't ask for credentials, you should probably add the --no_cookies flag.

ludwigvan16 tahun yang lalu

Yes, I did just as you suggested. Strange. Still no go.

ethnomusicolog16 tahun yang lalu

That is the really great part of the google brand. You can always bet that things will get better over time.

forgotAgain16 tahun yang lalu

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.

Now if they could just put node on there!

barfoomoo16 tahun yang lalu

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?

piotrSikora16 tahun yang lalu

It's been only removed for Task API... But why would do you need more than 30 seconds to process normal request?

barfoomoo16 tahun yang lalu

I was using it initially to do some scraping and it used to fail. But now I guess it can be done using the task api.

supersillyus16 tahun yang lalu

How often does one need/want requests to take longer than 30s? If it takes me more than ~5s to load a site, I typically go elsewhere.

joshstaiger16 tahun yang lalu

AppEngine's task queue uses http requests to do offline processing.

In fact the new limits only seem to apply to these types of requests — not user facing requests.

http://code.google.com/appengine/docs/python/taskqueue/overv...

[deleted]16 tahun yang lalu

thedangler16 tahun yang lalu

where is this Channel API I googled it didn't see anything.

bslatkin16 tahun yang lalu

Docs are on their way; just waiting for the push to complete.

alevi16 tahun yang lalu

Docs are here:

http://code.google.com/appengine/docs/python/channel/

http://code.google.com/appengine/docs/java/channel/

groks16 tahun yang lalu

The docs haven't been updated yet. Here this years IO video and pdf presentation:

http://www.google.com/events/io/2010/sessions/building-real-...

and here's the sample app (java):

http://code.google.com/p/dance-dance-robot

kaffeinecoma16 tahun yang lalu

Live demo: http://dance-dance-robot.appspot.com/

seiji16 tahun yang lalu