Skip to main content

Google App Engine / Java / cold Starup benchmarks (issues).

This is connected to the post in Google App Engine Group

Although Google Appengine gives out a java container, I had to roll back to the python code I used for version SarathOnline 3.1 – for a sole reason – perfromance. My (blog) site has a very low traffic (compared to what google thinks a regular traffic application). Averaging ~100 visits/day. All the css and js is dynamically generated. My current python code is doing pretty well servicing these requests @ a maximum of 2.something secs


Compare this with a java app that does MUCH less than what python does. I even add aremysitesup pingback for this app to leverage hot instances (actually not usefull at all – there are reports that even 20 spin downs do happen).


Google claims this to be an affecting only for low traffic applications. But there is a lot of hue and cry about how google spins down the application. But no matter what,
the first impression is the best impression.
Some have suggested to remove spring/di/jpa/jdo. While this is true, it solves much of the problem - These are the reason why I would choose java over python.

Version 1:
Is Grails Enabled
This one is totally unusable
03-30 01:27PM 36.488 / 500 30945ms 27164cpu_ms 0kb Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100316 Firefox/3.6.2,gzip(gfe)
See details
W 03-30 01:27PM 51.451
[sar/4.333911440567874888].: log4j:ERROR Error initializing log4j: is a restricted class. Please see the Google App Engine developer's guide for more details.
I 03-30 01:27PM 51.751
javax.servlet.ServletContext log: Initializing Spring root WebApplicationContext

Version 2:

Is Spring enabled. With Context Scan and eager loading and two contexts (app context, dispatcher context)


03-30 02:49PM 23.947 / 200 10519ms 5567cpu_ms 65api_cpu_ms 1kb gzip(gfe)
I 03-30 02:49PM 29.926
javax.servlet.ServletContext log: Initializing Spring root WebApplicationContext
03-30 02:49PM 31.715
org.springframework.web.context.ContextLoader initWebApplicationContext: Root WebApplicationContext: initialization completed in 1783 ms
03-30 02:49PM 33.074
org.springframework.web.servlet.FrameworkServlet initServletBean: FrameworkServlet 'dispatcher': initialization completed in 1083 ms

Version 3:
Is Spring enabled. With lazyloading and only one context with no component scan


03-30 02:18PM 06.867 /jscss/test.js 200 5296ms 4219cpu_ms 0kb Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv: Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729),gzip(gfe)
I 03-30 02:18PM 09.392
javax.servlet.ServletContext log: Initializing Spring FrameworkServlet 'dispatcher'
03-30 02:18PM 11.955
org.springframework.web.servlet.FrameworkServlet initServletBean: FrameworkServlet 'dispatcher': initialization completed in 2560 ms

Version 4:
Is powered by slim1.0.

03-30 02:04PM 45.810 /jscss/test.js 404 2408ms 1205cpu_ms 0kb Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/ Safari/532.5,gzip(gfe)
I 03-30 02:04PM 47.950
org.slim3.controller.FrontController init: Initialized FrontController(UUID:681f26f6-6d1c-4baf-8051-3968cc157836)

Version 5:
Plain old servlet, just logging


03-30 03:36PM 31.331 / 200 2752ms 1458cpu_ms 0kb Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC; OfficeLiveConnector.1.4; OfficeLivePatch.1.3),gzip(gfe)
D 03-30 03:36PM 33.838 service: /

For now, the groups have a hope that a kind of "Warm instances" will solve this issue. But are there no alternatives, technically?

Assuming  Google spins down just the apps - not the whole container.The probable reason could be most of the time taken should be during the class loading. Grails/Spring have a bunch of libraries that are almost 1 mb some times.

If that is true, a presumable solution would be to preload / share these libraries in the parent classloader and  have some kind of manifest either in app-web.xml or  to use them.  It may not be a fully loaded osgi type of a stack but a noval hierachied classloading with ways to selectively load libraries. Otherwise there be some other classloading mechanism that is fast. like probably from memcache.

What will Google do? We just have to wait and see.

Popular posts from this blog

Appcache manifest file issues/caveats

Application cache (appcache) is a powerful feature in HTML5. However, it does come with baggage. Many (see links below) advocated ferociously against it due to tricky issues it comes with. For someone who is just testing waters, these issues may throw them off grid. Knowing them before hand helps reduce some unpredictable effects.

Being a Vegetarian

I am a Proud Vegetarian. I don't eat Meat or Eggs. People say its hard here in US to be one. I beg to differ. The mere fact that I am hail and healthy these 4 years is a definitive proof. Apart from being bullied and trash talked by The Meat-Eaters, There is really nothing that makes this choice of mine any more than a debatable issue at a lunch or dinner. Other things aside, I am writing this blog having watched a PETA Video. Before you click on the play button, I ask you - If you are a vegetarian : Dont watch it. If you are not : Dare to watch it till the end. If you think going veg is just a fashion, think again . Even if you just want to do it for Fashion . Do it. Go Vegetarian. And Feel better asking the waiter for a Vegetarian Entrée in your next lunch.

Using Equinox CommandProvider to make OSGi console interactive.

After fiddling with the First Bundles that "Hello World"-ed upon Activation, You want to see more interactivity in OSGi. Although Using OSGi for an interactive Command Line Application would be like this one would be, well, a callable over-kill, I am going to start with an example and Expand it in later posts. So, please Welcome CommandProvider. CommandProvider is an EQUINOX specific API for extending the Console. This basic Example illustrates how to get a command from console and do something in java and also gets your feet wet on Service Registry package; import org. eclipse .osgi.framework.console .CommandInterpreter; import org.eclipse.osgi.framework.console.CommandProvider; public class DisplayMessageCommand implements CommandProvider { public void _say(CommandInterpreter ci) { ci.print("You said:" + ci.nextArgument()); } @Override public String getHelp() { return "\tsay - repeats what you say\n"; } }