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

image


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

image

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
image
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:1.9.2.2) 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: java.io.FileOutputStream 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)


image 


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

image 

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:1.9.2.2) 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.
image 

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/4.1.249.1042 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

image

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
com.so.smvc.RouterServlet 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 manifest.mf  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.
Labels:

Popular posts from this blog

Powered By

As it goes, We ought to give thanks to people who power us. This page will be updated, like the version page , to show all the tools, and people this site is Powered By! Ubuntu GIMP Firebug Blogger Google [AppEngine, Ajax and other Apis] AddtoAny Project Fondue jQuery
Read More >>

Decorator for Memcache Get/Set in python

I have suggested some time back that you could modularize and stitch together fragments of js and css to spit out in one HTTP connection. That makes the page load faster. I also indicated that there ways to tune them by adding cache-control headers. On the server-side however, you could have a memcache layer on the stitching operation. This saves a lot of Resources (CPU) on your server. I will demonstrate this using a python script I use currently on my site to generate the combined js and css fragments. So My stitching method is like this @memize(region="jscss") def joinAndPut(files, ext): res = files.split("/") o = StringIO.StringIO() for f in res: writeFileTo(o, ext + "/" + f + "." + ext) #writes file out ret = o.getvalue() o.close() return ret; The method joinAndPut is * decorated * by memize. What this means is, all calls to joinAndPut are now wrapped (at runtime) with the logic in memize. All you wa...
Read More >>

Faster webpages with fewer CSS and JS

Its easy, have lesser images, css and js files. I will cover reducing number of images in another post. But If you are like me, You always write js and css in a modular fashion. Grouping functions and classes into smaller files (and Following the DRY rule, Strictly!). But what happens is, when you start writing a page to have these css and js files, you are putting them in muliple link rel=style-sheet or script tags. Your server is being hit by (same) number of HTTP Requests for each page call. At this point, its not the size of files but the number server roundtrips on a page that slows your page down. Yslow shows how many server roundtrips happen for css and js. If you have more than one css call and one js call, You are not using your server well. How do you achieve this? By concatinating them and spitting out the content as one stream. So Lets say I have util.js, blog.js and so.js. If I have a blog template that depends on these three, I would call them in three script tags. Wh...
Read More >>