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,
Version 1:
Is Grails Enabled
This one is totally unusable
Version 2:
Is Spring enabled. With Context Scan and eager loading and two contexts (app context, dispatcher context)
Version 3:
Is Spring enabled. With lazyloading and only one context with no component scan
Version 4:
Is powered by slim1.0.
Version 5:
Plain old servlet, just logging
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.
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: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)
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: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.
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
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.