My naive understanding of the problem is that it takes a long time to initialize the jdo/jpa bridge over the datastore. I haven't had a chance to try out slim3, but Thomas was stating that the startup time for instances using slim3 is 1 to 3 seconds (I think). I believe this is because slim3 is a thin wrapper around the native datastore interface.
I would also really like to see the out-of-the-box implementation have a faster startup though. On Jun 15, 8:27 am, Rahul <[email protected]> wrote: > Jake, > > Thanks for giving me a heads up about this. > I have read that post in past but is there any official documentation > other then group posts which mentions something for this. I know we > can reduce the app start to 3-4 seconds but even that is something > which is not acceptable in various scenarios. > > Is there anything we can do to bring this issue on the top burner so > we can use our appengine apps for production purpose other then just > playing around with the stuff. > > Thanks, > Rahul > > On Jun 14, 1:10 pm, Jake <[email protected]> wrote: > > > > > Hey Rahul, > > > Seehttp://groups.google.com/group/google-appengine-java/browse_thread/th... > > for an official discussion of this issue. The first post talks about > > "discouraged" workarounds, but doesn't cite the 60-second ping > > specifically. This was the result, though, of a string of prior > > threads that discussed this issue and workaround. As you can see from > > the date, this is not a new problem. Again, I used the 60-second ping > > for awhile and it really didn't solve the problem - just ensured that > > the loading requests happened every 60 seconds :) > > > As for the framework, good point. I use Wicket which is pretty > > powerful. I've gotten it down to about 3-4 seconds load. One plugin > > had a dependency on Spring that I removed. As discussed > > here:http://code.google.com/p/objectify-appengine/wiki/BestPractices#Autom... > > anything that scans the classpath can be pretty demanding. > > > That being said, I'm not currently using my deployed application for > > demonstrations - I use a development server hosted on our own > > machines. My hope is that the restart issue will be resolved someday. > > > Jake > > > On Jun 11, 11:07 am, Rahul <[email protected]> wrote: > > > > Jake, > > > > Is there any official comments on this from google which says that it > > > discourage the pinging every 60 seconds or so. > > > > Also if we have some framework which we will always like to have if > > > doing some production application then what is the way out. > > > > Thanks, > > > Rahul > > > > On Jun 11, 10:16 am, Jake <[email protected]> wrote: > > > > > Hi Mark, > > > > > Yes, you can do better than 4.5 seconds without a framework. Also, > > > > there are layers that can be placed over the low level datastore (e.g > > > > Objectify) that add ease-of-use without noticeable additions to the > > > > startup time. > > > > > The 60 second pinging thing is, indeed, done by some users and is > > > > officially discouraged by Google. At one point, I set up a similar > > > > pinging feature and found that it really didn't work. Theoretically > > > > it should, but the pings just caused loading requests every minute or > > > > so, which simply reduced the likelihood that a user would see the > > > > loading request; it didn't solve the problem. > > > > > Jake > > > > > On Jun 11, 7:32 am, Mark <[email protected]> wrote: > > > > > > Hi, just joining in, trying to sum up: > > > > > > In the best case (if we only use the low level datastore + no > > > > > frameworks on top) we can only hope that a fresh restart of our app > > > > > will take 4.5 seconds? > > > > > > However if at least one user is hitting the site every 60 seconds from > > > > > somewhere in the world, then our app should be kept alive and no need > > > > > for restarts? > > > > > > Not that I'm planning on doing it, but what prevents developers from > > > > > simply pinging the site every 60 seconds to force the app to stay in > > > > > memory? I ask what prevents it because if I play by the rules, I'm > > > > > going to get penalized if other developers are 'cheating' and doing > > > > > the artificial pinging, > > > > > > Thanks > > > > > > On Jun 9, 5:49 am, Jake <[email protected]> wrote: > > > > > > > Hey Tin, > > > > > > > Several people were using GAE's built in timing mechanism to ping > > > > > > the > > > > > > server to accomplish the same thing. Google came out and officially > > > > > > discouraged this as it tends to throw off any attempts they are > > > > > > currently making to fix the problem. I can't tell people what to > > > > > > do, > > > > > > but I opted to stop using this hack in the hopes that they will > > > > > > solve > > > > > > the problem. > > > > > > > Besides, you'll notice that this hack doesn't really work over the > > > > > > long run. It will essentially restart your server every minute and > > > > > > won't really prevent the loading request from falling on your users > > > > > > instead of on your ping. > > > > > > > Jake > > > > > > > On Jun 8, 1:54 pm, Tin <[email protected]> wrote: > > > > > > > > Hi all: > > > > > > > > We have found a temporary solution for this issue: > > > > > > > Try with an AJAX timer kicking the server (doing nothing), maybe > > > > > > > one > > > > > > > request per minute (or less) and GAE will keep our site / users > > > > > > > in the > > > > > > > same node. > > > > > > > In our testing it could avoid the GAE web instance reloaded, but > > > > > > > if > > > > > > > the request interval is long, it would cause another Datastore > > > > > > > performance issue:http://goo.gl/98zkthatwillbefixedinnear > > > > > > > future. > > > > > > > > More info please refer to here:http://goo.gl/mzQR -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
