Cool post Sarath, thanks for sharing. I'm also scrambling to get better performance, but I'm getting nowhere near as high CPU times as you are. What types of queries are you doing? I've restructured my app so that all of my queries are by keys. I've denormalized, serialized child objects into parents when I didn't need to query the children.
I'm not going to assume I know what your app's doing, and starting handing out advice on ignorance, but we all need to accept that this isn't a traditional relational data store. We need to do more with our write operations in preparation for specific read operations. Trade-offs need to be made with every request. Even with 100 views per day, our app is basically in a system that's getting pummeled, so we need to code as if we're getting 1million pageviews per day. There's all kinds of tricks you can do (again, assuming you're not doing them already). If the CSS is dynamically generated, cache it and/or store it as a text field in a table. Use AJAX to give the perception of a quick-loading app by putting as much into the html files as you can, with spinners on the client as the data is loaded asynchronously. That extra work will even save you money once you get above the free quota. What are you doing in those requests that can't be cleaned up for better App Engine performance? - a side note to this thread, not necessarily Sarath - I agree with everyone on what "would be nice". I'd love to make a fully relational database that handles ad hoc queries and no awareness of the underlying framework, but the system is what it is, so let's embrace it and squeeze every cpu clock cycle and millisecond of wait time out of it. If we can't do that, then why don't we just move to LAMP hosts for $10/month? On Mar 31, 10:19 am, Sarath <sarath...@yahoo.com> wrote: > Here is some more insight.http://bit.ly/d2lOnv > > Looks like I was way off on numbers for Grails. Like I said, We should > think less about work arounds, and frameworks-on-diet (not that they > dont work) and rather look at an out of box solution. > > -Sarath. > > On Mar 31, 2:29 am, Sarath <sarath...@yahoo.com> wrote: > > > This is getting really interesting. I have been follwoing this post > > from a couple of days. > > > I managed to see What exactly is ammounting to delayed startup. > > > 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. > > > I may be wrong here - But I tried this experiment. > > > I had four versions of a simple java app. > > > one with grails > > one with spring (full di - context: scan etc) > > one with spring (lazyloading, ) > > one with slim1.0 > > one with NOTHING (only commons logging) > > > I realised there are two parts to the load time. > > > The load time from google. > > The load time from the libraries. > > > I believe from a developers perspective the second one should NOT be > > considered for optimization. > > > For #1 a recommendation is warm startup. While in theory it might > > sound good, the elasticity and managment will take it back to EC2 type > > like baz suggests. > > > For my experiment the results are like this > > > Version - > > Google Warmup - Framework Warmup > > with grails > > - ~9+ secs - ~4secs > > with spring (full di - context: scan etc) - > > ~4+ secs - ~3 secs > > with spring (lazyloading, ) - > > ~4 secs - ~2 secs > > with slim1.0 - > > ~2-3 secs - <1 secs > > with NOTHING (only commons logging) - ~2 secs - > > <1 sec > > > Now I dont know what exactly Google spins down - I assume just the > > apps - not the whole container. In which case, There is a lot of load > > while loading the libraries. I can only guess, (corrections expected > > from technical team at google) most of the time take should be during > > the class loading. Grails/Spring have a bunch of libraries that are > > almost 1 mb some times. > > > An assumable 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. > > > Google tech team - to comment/ > > > I will try to upload some actual numbers from my logs and post the > > information. > > > -Sarath > > > On Mar 31, 1:54 am, "Ikai L (Google)" <ika...@google.com> wrote: > > > > David, that post mirrors many of the points made here: > > > >http://www.answercow.com/2010/03/google-app-engine-cold-start-guide-f... > > > > There's one or two more tips on that page. > > > > On Tue, Mar 30, 2010 at 12:47 PM, David Chandler > > > <turboman...@gmail.com>wrote: > > > > > In the mean time, here are some ideas for reducing startup times by > > > > shrinking our apps. I went from 8.1s to 2.5s mainly by eliminating > > > > Guice, and I would expect similar results with Spring. I can > > > > definitely live with 2.5s... > > > > >http://turbomanage.wordpress.com/2010/03/26/appengine-cold-starts-con... > > > > > /dmc > > > > > On Mar 30, 3:04 pm, Baz <b...@thinkloop.com> wrote: > > > > > Great information, Ikai. > > > > > > I really feel that "instances" should be completely avoided in concept > > > > and > > > > > language on the GAE. What if the feature was simply an enable/disable > > > > deal > > > > > called "Warm Scale". If it were enabled, then your *next* instance > > > > > would > > > > > always be warm, regardless of how many instances you already had. This > > > > would > > > > > be most noticeable and suitable for low QPS production apps that are > > > > > constantly going from 0 to 1 instances (as you mentioned), but it > > > > > could > > > > > still be important for others, say, for a super-high-profile site, or > > > > > a > > > > > situation where your QPS is right at the threshold of instances and > > > > > oscillating back and forth between two instances. Whatever the > > > > > situation, > > > > if > > > > > the solution were generalized like that, and most importantly not > > > > > tied to > > > > a > > > > > SPECIFIC NUMBER of instances, it would be up to the user to decide how > > > > > important it was for them and whether to enable it. > > > > > > Cheers, > > > > > Baz > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "Google App Engine for Java" group. > > > > To post to this group, send email to > > > > google-appengine-j...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com> > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/google-appengine-java?hl=en. > > > > -- > > > Ikai Lan > > > Developer Programs Engineer, Google App > > > Enginehttp://googleappengine.blogspot.com|http://twitter.com/app_engine -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
