The Limitations of Google App Engine

I have a very simple test application up on Google App Engine. See gregrluckapphelloworld.appspot.com.

80MB heap limit

Go to gregrluckapphelloworld.appspot.com. Each time you hit is exactly 10MB gets added to Ehcache in-process cache. This is an intentiontal memory leak designed to find out how much you stick in the heap.

The answer is around 80MB. I suspect, taking Jetty into account that there is an -Xmx100m setting in play.

Crashed sites do not recover immediately or start a new instance.Update Feb 2010: Now they do

When you get an OutOfMemory error the site is cooked. There should be some monitoring that notices and takes it down. That is not the case.

I have a wget script which, every 30 seconds, does

while true; do wget "http://gregrluckapphelloworld.appspot.com/"; sleep 30;  done;

The answer is that the dead site stays down for 5 minutes (10 repetitions of my script). And no new instance gets fired up. Your whole site is down.

Update: Google fixed this as of February 2010.

Static content is not distributed through the Google CDN

On the page I put an image. I did not configure it as static. I downloaded it and got the IP 74.125.19.141 which is in Mountain View, California.
I then marked the images as static in appengine-web-app and redeployed.
There was no effect on the serving location or speed of download.
It may be that the files are served from the static content location
You would expect this to be distributed via Google’s CDN.
Here is the header you get from the static content servers.

HTTP/1.0 200 OK
Date: Tue, 16 Jun 2009 09:47:01 GMT
Expires: Tue, 16 Jun 2009 09:57:01 GMT
Cache-Control: public, max-age=600
Content-Type: image/jpeg
Server: Google Frontend
Content-Length: 237952
Connection: Keep-Alive

Another interesting thing – cache expiry is set to 10 minutes. A CDN will normally set the TTL longer and rely on a technique such as resource renaming to overcome browser cache issues.

Conclusion

None of this is good. The first is a very serious limitation. The last two are killers for running a production app. Hopefully Google will fix these things.

Published
Categorized as Java

By Greg Luck

As Terracotta’s CTO, Greg (@gregrluck) is entrusted with understanding market and technology forces and the business drivers that impact Terracotta’s product innovation and customer success. He helps shape company and technology strategy and designs many of the features in Terracotta’s products. Greg came to Terracotta on the acquisition of the popular caching project Ehcache which he founded in 2003. Prior to joining Terracotta, Greg served as Chief Architect at Australian online travel giant Wotif.com. He also served as a lead consultant for ThoughtWorks on accounts in the United States and Australia, was CIO at Virgin Blue, Tempo Services, Stamford Hotels and Resorts and Australian Resorts and spent seven years as a Chartered Accountant in KPMG’s small business and insolvency divisions. He is a regular speaker at conferences and contributor of articles to the technical press.

1 comment

  1. Don’t forget it is an ‘early look’ after all… am sure they are working on this. Given that Amazon are charging for the use of their ‘CDN-lite’ (CloudFront) in EC2 apps, I wonder whether Google (should they bolt content distribution capabilities onto GAE) will be disruptive and NOT charge for it?

Comments are closed.