[appengine-java] Re: Performance issue for GAE auto-restart
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 jbrooko...@cast.org 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 rahul.jun...@gmail.com 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 jbrooko...@cast.org 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 mar...@gmail.com 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 jbrooko...@cast.org 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 tin.c...@gmail.com 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 google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email
[appengine-java] Re: Performance issue for GAE auto-restart
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 rahul.jun...@gmail.com 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 jbrooko...@cast.org 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 rahul.jun...@gmail.com 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 jbrooko...@cast.org 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 mar...@gmail.com 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 jbrooko...@cast.org 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 tin.c...@gmail.com wrote: Hi all: We have found a temporary solution for this issue: Try with an AJAX timer kicking the server (doing nothing), maybe
[appengine-java] Re: Performance issue for GAE auto-restart
Hi Rahul: For the official documentation please refer to http://code.google.com/intl/en/appengine/kb/java.html#Should_I_Run_A_Cron_Job On 6月15日, 下午11時27分, Rahul rahul.jun...@gmail.com 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 jbrooko...@cast.org 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 rahul.jun...@gmail.com 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 jbrooko...@cast.org 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 mar...@gmail.com 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 jbrooko...@cast.org 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 tin.c...@gmail.com 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
[appengine-java] Re: Performance issue for GAE auto-restart
Hey Rahul, See http://groups.google.com/group/google-appengine-java/browse_thread/thread/b57e6c4895333fa8/f5196d61f7f2 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#Automatic_Scanning 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 rahul.jun...@gmail.com 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 jbrooko...@cast.org 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 mar...@gmail.com 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 jbrooko...@cast.org 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 tin.c...@gmail.com 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/98zkthatwillbefixedin near 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 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.
[appengine-java] Re: Performance issue for GAE auto-restart
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 jbrooko...@cast.org 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 tin.c...@gmail.com 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/98zkthatwill be fixed in near 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 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hi Mark: The 4.5 seconds is for struts 1.2 in my case. The startup time of 1.3~3.9 seconds is reported by using a more lightweight framework (slim3). Please refer to http://groups.google.com/group/slim3-user/browse_thread/thread/e9d2f7a52f3408 On 6月11日, 下午7時32分, Mark mar...@gmail.com 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? -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
It would be great if JPA/JDO could be disabled in the Google eclipse
plugin.
I don't need it, but I've not yet figured out how to get rid of the
jars...
On 7 Jun., 17:59, Jake jbrooko...@cast.org wrote:
Hi all,
@Thomas: I will look into that, thank you. The way we generate our
pages in this framework, however, involves some interesting dynamic
generation of image URLs that are mounted within the application
itself. It ends up being a bit more complicated than just displaying
one string or another for the src attribute. Whether this is a good
practice on GAE is certainly up for debate, but I presume this
wouldn't help the frequent restart issue, correct? It just means that
fewer files would be able to trigger a restart?
@Tin: I'm not sure I understand what I will learn from this. From
what I understand, contextDestroyed() is never called so all I would
see is an additional log statement near GAE's loading request logging
line? I've never used a ServletContextListener, so perhaps it has
other features that I'm not aware of?
Thanks!
Jake
On Jun 7, 11:41 am, Tin tin.c...@gmail.com wrote:
Hi Jack:
I suggest that maybe you can write a ServletContextListener to monitor
the web instance reloading issue, for our testing we just put a info
logging in the contextInitialized(..) method:
public void contextInitialized(ServletContextEvent evt) {
log.info(Web context inited.);
}
And modify the DEFAULT logging level to INFO in the logging.properties
file. If the web instance was reloaded, we could trace this in the
logging messages.
--
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.
[appengine-java] Re: Performance issue for GAE auto-restart
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 mar...@gmail.com 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 jbrooko...@cast.org 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 tin.c...@gmail.com 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/98zkthatwillbe fixed in near 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 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.
[appengine-java] Re: Performance issue for GAE auto-restart
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 jbrooko...@cast.org 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 mar...@gmail.com 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 jbrooko...@cast.org 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 tin.c...@gmail.com 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/98zkthatwillbefixed in near 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 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.
Re: [appengine-java] Re: Performance issue for GAE auto-restart
Hmm ok I see, so I'm just using JDO without any frameworks on top of that, but as mentioned in the slim3 tests, JDO does add overhead (sometimes a significant amount). I don't plan to be doing any large queries (the slim3 example fetches 10,000 objects which I don't plan on doing at any point), but what is important to me is that startup time. One to two seconds is fine, four seconds starts pushing it, anything above that is pretty bad. If we start using slim3 though, we lose the flexibility in moving to another host (not that I know of any that can compare to app engine) since it'll be interacting directly with big table instead of using jdo or jpa is an intermediate? Thanks On Fri, Jun 11, 2010 at 8:07 AM, Rahul rahul.jun...@gmail.com 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 jbrooko...@cast.org 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 mar...@gmail.com 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 jbrooko...@cast.org 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 tin.c...@gmail.com 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/98zkthatwillbefixed in near 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 google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hi: You can define the dao interfaces and write the implementation of the interfaces with datastore low level api or some fast startup framework other than JDO or JPA. If you need to migrate to other platform which supports standard RDBMS, you implement the dao interface with JDO, JPA or JDBC. The entity relationship model design in appengine is very different from other RDBMS. You can not use more than two inequality filters or the 'OR' operator in your query. So the design which works great with appengine is probably not good with RDBMS and vice versa. I think even the model redesign is necessary when you leave appengine. Unless you don't choose to use appengine, use JDO(JPA) save you nothing. On 6月12日, 上午1時07分, Mark Wyszomierski mar...@gmail.com wrote: Hmm ok I see, so I'm just using JDO without any frameworks on top of that, but as mentioned in the slim3 tests, JDO does add overhead (sometimes a significant amount). I don't plan to be doing any large queries (the slim3 example fetches 10,000 objects which I don't plan on doing at any point), but what is important to me is that startup time. One to two seconds is fine, four seconds starts pushing it, anything above that is pretty bad. If we start using slim3 though, we lose the flexibility in moving to another host (not that I know of any that can compare to app engine) since it'll be interacting directly with big table instead of using jdo or jpa is an intermediate? Thanks -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
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 tin.c...@gmail.com 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/98zkthat will be fixed in near 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 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.
[appengine-java] Re: Performance issue for GAE auto-restart
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/98zk that will be fixed in near 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 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hey, The logs show what is being GET for any message. When loading some pages, I noticed that, beyond the initial delay of the page, I saw an 8s delay on one of the javascript files that was referenced in the code. When I checked the GAE logs, I saw a startup request for the initial GET for the HTML and then one immediately following GET for the javascript file. I suppose it is possible that this was a new instance spawning (instead of a restart), but I find that unlikely since I was the only user of my application. Or, if it is the case that GAE needs to spawn multiple JVMs to support one full page request, I think that is a problem :) Anyways, end result is that from a period of inactivity with no instances running, I went to my homepage once and saw two loading requests in the logs right after one another for that single page load. This has happened more than once. Granted, it's now been a couple of weeks since I last tested this behavior, but I haven't heard any feedback on my issue to suggest that it has changed. Jake On Jun 5, 8:45 pm, Thomas mylee...@gmail.com wrote: Hi Jake: I am curious about how do you know there were 2 startup during one request? Did you submit an issue about the phenomenon? On 6月6日, 上午2時34分, Jake jbrooko...@cast.org wrote: Hey Thomas, I get it all the time - to the point where all of my demonstration applications are using the development server hosted on a non-GAE machine :) Anyways, Ikai is (was) aware of the issue from awhile back, but I'm not sure it's taking priority. Jake -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hey, Here's a concrete example. One page load, 3 loading requests: one for the library page, another for a CSS file for that page, and a third for an image on that page. The end result, after a lot of optimization, is 24 seconds from initial page arrival to full display. And, it's likely that by the time the page has displayed, the JVM instance has shut down and the next user interaction will cause another loading request. 05-27 08:59AM 16.068 /resources/indira/img/buttons/share_o.png 200 4665ms 4160cpu_ms 1kb Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3,gzip(gfe) 05-27 08:59AM 20.707 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application. 05-27 08:59AM 05.109 /resources/org.apache.wicket.Application/css/ tht.css 200 4014ms 3946cpu_ms 0kb Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3,gzip(gfe) 05-27 08:59AM 09.100 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application. 05-27 08:58AM 56.380 /library;jsessionid=fU8dpFQMEe1Ec3BqNEY2vQ 200 8394ms 8142cpu_ms 170api_cpu_ms 3kb Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/ 3.6.3,gzip(gfe) 05-27 08:59AM 04.773 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application. Thanks! Jake On Jun 7, 9:40 am, Jake jbrooko...@cast.org wrote: Hey, The logs show what is being GET for any message. When loading some pages, I noticed that, beyond the initial delay of the page, I saw an 8s delay on one of the javascript files that was referenced in the code. When I checked the GAE logs, I saw a startup request for the initial GET for the HTML and then one immediately following GET for the javascript file. I suppose it is possible that this was a new instance spawning (instead of a restart), but I find that unlikely since I was the only user of my application. Or, if it is the case that GAE needs to spawn multiple JVMs to support one full page request, I think that is a problem :) Anyways, end result is that from a period of inactivity with no instances running, I went to my homepage once and saw two loading requests in the logs right after one another for that single page load. This has happened more than once. Granted, it's now been a couple of weeks since I last tested this behavior, but I haven't heard any feedback on my issue to suggest that it has changed. Jake On Jun 5, 8:45 pm, Thomas mylee...@gmail.com wrote: Hi Jake: I am curious about how do you know there were 2 startup during one request? Did you submit an issue about the phenomenon? On 6月6日, 上午2時34分, Jake jbrooko...@cast.org wrote: Hey Thomas, I get it all the time - to the point where all of my demonstration applications are using the development server hosted on a non-GAE machine :) Anyways, Ikai is (was) aware of the issue from awhile back, but I'm not sure it's taking priority. Jake -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hi Jake: By default, all css/image files should be treated as static files. It seems that your css/image files were not served as static files. I think you should check your static files setting. Please refer to http://code.google.com/intl/en/appengine/docs/java/config/appconfig.html#Static_Files_and_Resource_Files Hope it helps! -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hi Jack:
I suggest that maybe you can write a ServletContextListener to monitor
the web instance reloading issue, for our testing we just put a info
logging in the contextInitialized(..) method:
public void contextInitialized(ServletContextEvent evt) {
log.info(Web context inited.);
}
And modify the DEFAULT logging level to INFO in the logging.properties
file. If the web instance was reloaded, we could trace this in the
logging messages.
--
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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hi all,
@Thomas: I will look into that, thank you. The way we generate our
pages in this framework, however, involves some interesting dynamic
generation of image URLs that are mounted within the application
itself. It ends up being a bit more complicated than just displaying
one string or another for the src attribute. Whether this is a good
practice on GAE is certainly up for debate, but I presume this
wouldn't help the frequent restart issue, correct? It just means that
fewer files would be able to trigger a restart?
@Tin: I'm not sure I understand what I will learn from this. From
what I understand, contextDestroyed() is never called so all I would
see is an additional log statement near GAE's loading request logging
line? I've never used a ServletContextListener, so perhaps it has
other features that I'm not aware of?
Thanks!
Jake
On Jun 7, 11:41 am, Tin tin.c...@gmail.com wrote:
Hi Jack:
I suggest that maybe you can write a ServletContextListener to monitor
the web instance reloading issue, for our testing we just put a info
logging in the contextInitialized(..) method:
public void contextInitialized(ServletContextEvent evt) {
log.info(Web context inited.);
}
And modify the DEFAULT logging level to INFO in the logging.properties
file. If the web instance was reloaded, we could trace this in the
logging messages.
--
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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hey Thomas, I get it all the time - to the point where all of my demonstration applications are using the development server hosted on a non-GAE machine :) Anyways, Ikai is (was) aware of the issue from awhile back, but I'm not sure it's taking priority. Jake On Jun 4, 1:33 am, Thomas mylee...@gmail.com wrote: On 6月4日, 下午12時02分, Jake jbrooko...@cast.org wrote: I understand that there can be problems with everyone having a full- time reserved JVM. My problem is simply that the instance restarts too frequently. I mean, honestly, one SINGLE page request results in TWO application restarts? Even if you get it down to 4 seconds, that's 8-10 seconds just for the page to load. I personally have never seen the two continuous app loading in a single request before. Maybe you should open an issue to let google guy's help you. I confess, I'm not an expert on the technology involved. Is it technologically difficult to say, if a JVM gets any traffic, hold it open for 5 minutes at a minimum. This can be cheated by the keep alive pinging that people are doing, but perhaps that can be ignored and only external traffic counts? I guess google can't tell the 'keep alive' tasks from normal tasks without reverse engineering the code. Banning 'keep alive' task will kill the normal tasks also probably. -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hi Jake: I am curious about how do you know there were 2 startup during one request? Did you submit an issue about the phenomenon? On 6月6日, 上午2時34分, Jake jbrooko...@cast.org wrote: Hey Thomas, I get it all the time - to the point where all of my demonstration applications are using the development server hosted on a non-GAE machine :) Anyways, Ikai is (was) aware of the issue from awhile back, but I'm not sure it's taking priority. Jake -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hi all:
We have used this Slim3 framework to do the Counter testing, the
result still has the same problem, but we feel that Slim3 actually is
a very greate framework for GAE, if this performance issue can be
resolved we will use Slim3 to rewrite our project. Otherwise we need
changing to use other plantform.
Thanks Thomas very much for the Slim3 information, thank you !!!
-- Test Servlet --
Counter counter = service.increase();
requestScope(count, counter.getCount());
return forward(index.jsp);
-- Test JSP --
%...@page pageEncoding=UTF-8 isELIgnored=false session=false%
%...@taglib prefix=c uri=http://java.sun.com/jsp/jstl/core%
%...@taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions%
%...@taglib prefix=f uri=http://www.slim3.org/functions%
html
head
meta http-equiv=Content-Type content=text/html; charset=UTF-8 /
titletwitter Index/title
/head
body
h1Count: ${count}/h1
/body
/html
-- Log Messages --
06-04 12:56AM 55.826 /twitter/ 200 3895ms 3814cpu_ms 100api_cpu_ms ---
FIRST REQUEST, SPEND 3.8sec
06-04 12:56AM 56.871 org.slim3.controller.FrontController init:
Initialized FrontController
06-04 12:56AM 58.405 stdout: Request /twitter/ spend 1458 ms
...
06-04 12:56AM 59.695 stdout: Request /twitter/ spend 123 ms ---
GOOD PERFORMANCE
...
06-04 12:57AM 01.925 stdout: Request /twitter/ spend 119 ms ---
GOOD PERFORMANCE
...
06-04 01:01AM 32.046 /twitter/ 200 4182ms 3989cpu_ms 100api_cpu_ms ---
AUTO-RELOAD !!, SPEND 4.1sec
06-04 01:01AM 34.512 org.slim3.controller.FrontController init:
Initialized FrontControlle
06-04 01:01AM 36.209 stdout: Request /twitter/ spend 1592 ms
...
--
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.
Re: [appengine-java] Re: Performance issue for GAE auto-restart
What about Gaelyk? (as you brought the topic on the Gaelyk google group too) :-)
http://gaelyk.appspot.com/
On Fri, Jun 4, 2010 at 10:20, Tin tin.c...@gmail.com wrote:
Hi all:
We have used this Slim3 framework to do the Counter testing, the
result still has the same problem, but we feel that Slim3 actually is
a very greate framework for GAE, if this performance issue can be
resolved we will use Slim3 to rewrite our project. Otherwise we need
changing to use other plantform.
Thanks Thomas very much for the Slim3 information, thank you !!!
-- Test Servlet --
Counter counter = service.increase();
requestScope(count, counter.getCount());
return forward(index.jsp);
-- Test JSP --
%...@page pageEncoding=UTF-8 isELIgnored=false session=false%
%...@taglib prefix=c uri=http://java.sun.com/jsp/jstl/core%
%...@taglib prefix=fn uri=http://java.sun.com/jsp/jstl/functions%
%...@taglib prefix=f uri=http://www.slim3.org/functions%
html
head
meta http-equiv=Content-Type content=text/html; charset=UTF-8 /
titletwitter Index/title
/head
body
h1Count: ${count}/h1
/body
/html
-- Log Messages --
06-04 12:56AM 55.826 /twitter/ 200 3895ms 3814cpu_ms 100api_cpu_ms ---
FIRST REQUEST, SPEND 3.8sec
06-04 12:56AM 56.871 org.slim3.controller.FrontController init:
Initialized FrontController
06-04 12:56AM 58.405 stdout: Request /twitter/ spend 1458 ms
...
06-04 12:56AM 59.695 stdout: Request /twitter/ spend 123 ms ---
GOOD PERFORMANCE
...
06-04 12:57AM 01.925 stdout: Request /twitter/ spend 119 ms ---
GOOD PERFORMANCE
...
06-04 01:01AM 32.046 /twitter/ 200 4182ms 3989cpu_ms 100api_cpu_ms ---
AUTO-RELOAD !!, SPEND 4.1sec
06-04 01:01AM 34.512 org.slim3.controller.FrontController init:
Initialized FrontControlle
06-04 01:01AM 36.209 stdout: Request /twitter/ spend 1592 ms
...
--
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.
--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
--
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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hi all: We extremity love the HOT reloading, annotation processing and junit testing support (Kotori Web Runner integrated) features of Slim3. If you plan to use GAE please consider this framework it will make you feel so happy. Slim3 Home : http://goo.gl/urLV -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Dear Guillaume: The GAE auto-restarting issue will make us give up using Gaelyk because the TemplateServlet needs more time to init, if this issue can't be resolved quickly we even consider to change to other platform. But we very hope the GAE team could pay more attention to this critical issue as long as we have wrote lots code using Groovy and Gaelyk. The HOT reloading, annotation processing and junit testing support (Kotori Web Runner integrated) features of Slim3 get a shine in my eye, I think Gaelyk also can get some ideas form Slim3 framework. In addition if we rewrite our project by Slim3, we can still use Groovy as the coding language and steal some key features from Gaelyk. :-) -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
There are three common approaches. 1. Use App Engine for Business. 2. Wait for 'paid to reserve JVM feature'. 3. Use lightweight framework. -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Sorry! I made a mistake. The GAE for Business page ( http://code.google.com/intl/en/appengine/business/ ) doesn't mention anything about loading request. The No#1 approach is void. On 6月3日, 下午5時08分, Thomas mylee...@gmail.com wrote: There are three common approaches. 1. Use App Engine for Business. 2. Wait for 'paid to reserve JVM feature'. 3. Use lightweight framework. -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Dear Thomas: Thanks for your quickly reply very much !!! 2. Wait for 'paid to reserve JVM feature'. Do you have more information about this ? 3. Use lightweight framework. What lightweight framework did you mean for ? In this testing we just using Servlet and JSP that's recommend by GAE. Thank you again !!! -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hello, If you don't like this general behavior, please star this issue: http://code.google.com/p/googleappengine/issues/detail?id=2931 I see comments like this pop up all the time, but we must be a rarity. Anyways, regarding the pay to reserve JVM see this issue: http://code.google.com/p/googleappengine/issues/detail?id=2456 I personally don't like this solution as it seems to be paying for minimum functionality. Thanks! Jake On Jun 3, 9:34 am, Tin tin.c...@gmail.com wrote: Dear Thomas: Thanks for your quickly reply very much !!! 2. Wait for 'paid to reserve JVM feature'. Do you have more information about this ? 3. Use lightweight framework. What lightweight framework did you mean for ? In this testing we just using Servlet and JSP that's recommend by GAE. Thank you again !!! -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hi Jack: Thanks for your reply very much !!! If you don't like this general behavior, please star this issue: http://code.google.com/p/googleappengine/issues/detail?id=2931 YES I have stared this issue, I think every body who uses GAE should star this issue ^^|| I personally don't like this solution as it seems to be paying for minimum functionality. You're righit, but if we can pay little $$ for fixing this BIG issue we will do it. || Thanks lots again !! -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
IMHO, 'Pay to reserve a JVM' is much more reasonable. Although everybody likes free lunch, but the resources will be wrongly allocated eventually. For example, the rival company of Google can legally eat up all its RAM by submitting tremendous amount of huge size application if there is no recycling. The most valuable feature of GAE/J which makes it uniquely different from an ordinary VPS is the scalability and zero administration of the scalable cloud. This unique feature is worth paying for a fast growing business. My project is in development phase and I don't enable billing neither. So I choose to make my app start faster. I use struts 1.2.x + Spring 2.0 initially. But quickly I realized I had to get rid of Spring in order to decrease the startup time. So I wrote a TidyDelegationProxy (tidy means TIny DependencY injector) to replace Spring's struts proxy. I successfully reduced the startup CPU time from 12+ seconds to 6 seconds. And I replace the configuration XML parsing with deserialized the pre-parsed struts config from the resource. The startup CPU time reduced to 4.3 seconds. FYI the slim3 framework ( http://sites.google.com/site/slim3appengine/ ) has a mini controller which is claimed to be lightweight. I personally use the datastore related api (which is great) of slim3 only, but you may evaluate if the controller api is suitable for you. If you don't like this general behavior, please star this issue: http://code.google.com/p/googleappengine/issues/detail?id=2931 YES I have stared this issue, I think every body who uses GAE should star this issue ^^|| I personally don't like this solution as it seems to be paying for minimum functionality. You're righit, but if we can pay little $$ for fixing this BIG issue we will do it. || Thanks lots again !! -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
I use struts 1.2.x + Spring 2.0 initially. But quickly I realized I had to get rid of Spring in order to decrease the startup time. So I wrote a TidyDelegationProxy (tidy means TIny DependencY injector) to replace Spring's struts proxy. I successfully reduced the startup CPU time from 12+ seconds to 6 seconds. Correct some mistakes. I use struts 1.2.x + Spring 2.0 + JDO initially. But quickly I realized I had to get rid of Spring and JDO in order to decrease the startup time. So I used slim3 and wrote a TidyDelegationProxy to replace Spring's struts proxy. I successfully reduced the startup CPU time from 12+ seconds to 6 seconds. -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
I understand that there can be problems with everyone having a full- time reserved JVM. My problem is simply that the instance restarts too frequently. I mean, honestly, one SINGLE page request results in TWO application restarts? Even if you get it down to 4 seconds, that's 8-10 seconds just for the page to load. I confess, I'm not an expert on the technology involved. Is it technologically difficult to say, if a JVM gets any traffic, hold it open for 5 minutes at a minimum. This can be cheated by the keep alive pinging that people are doing, but perhaps that can be ignored and only external traffic counts? Jake On Jun 3, 8:21 pm, Thomas mylee...@gmail.com wrote: I use struts 1.2.x + Spring 2.0 initially. But quickly I realized I had to get rid of Spring in order to decrease the startup time. So I wrote a TidyDelegationProxy (tidy means TIny DependencY injector) to replace Spring's struts proxy. I successfully reduced the startup CPU time from 12+ seconds to 6 seconds. Correct some mistakes. I use struts 1.2.x + Spring 2.0 + JDO initially. But quickly I realized I had to get rid of Spring and JDO in order to decrease the startup time. So I used slim3 and wrote a TidyDelegationProxy to replace Spring's struts proxy. I successfully reduced the startup CPU time from 12+ seconds to 6 seconds. -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Dear Thomas: Correct some mistakes. I use struts 1.2.x + Spring 2.0 + JDO initially. But quickly I realized I had to get rid of Spring and JDO in order to decrease the startup time. So I used slim3 and wrote a TidyDelegationProxy to replace Spring's struts proxy. I successfully reduced the startup CPU time from 12+ seconds to 6 seconds. Thanks very much for those useful information, if this issue can be solved I will try to use them in our project. 'Pay to reserve a JVM' is much more reasonable. Although everybody likes free lunch, but the resources will be wrongly allocated eventually. If the price is reasonable we will pay for this function happily, because without this GAE will only be suitable for a testing or toy app. Thank you for your kindly reply again !! -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Dear Jack: I understand that there can be problems with everyone having a full- time reserved JVM. My problem is simply that the instance restarts too frequently. I mean, honestly, one SINGLE page request results in TWO application restarts? Even if you get it down to 4 seconds, that's 8-10 seconds just for the page to load. I'm VERY VERY agree with this, the instance restarting is TOO frequently, even we just use Servlet + JSP the performance still can't be accepted. I don't think this'e a reasonable behavior of a production web container. But maybe we just can start this open issue (http://goo.gl/juDy) to push GAE team helping us as soon as possible, I think my boss will be angry for this answer. __ Thanks a lot for your reply !!! -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Hi Tin: I'm VERY VERY agree with this, the instance restarting is TOO frequently, even we just use Servlet + JSP the performance still can't be accepted. I don't think this'e a reasonable behavior of a production web container. In your case, the problem is due to JAP. If you want to have quick startup time, you MUST get rid of JPA/JDO and use some other lightweight persistence api (Slim3, Objectify, Twig, ...) or use low level datastore api directly to access the datastore. -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
On 6月4日, 下午12時02分, Jake jbrooko...@cast.org wrote: I understand that there can be problems with everyone having a full- time reserved JVM. My problem is simply that the instance restarts too frequently. I mean, honestly, one SINGLE page request results in TWO application restarts? Even if you get it down to 4 seconds, that's 8-10 seconds just for the page to load. I personally have never seen the two continuous app loading in a single request before. Maybe you should open an issue to let google guy's help you. I confess, I'm not an expert on the technology involved. Is it technologically difficult to say, if a JVM gets any traffic, hold it open for 5 minutes at a minimum. This can be cheated by the keep alive pinging that people are doing, but perhaps that can be ignored and only external traffic counts? I guess google can't tell the 'keep alive' tasks from normal tasks without reverse engineering the code. Banning 'keep alive' task will kill the normal tasks also probably. -- 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.
[appengine-java] Re: Performance issue for GAE auto-restart
Dear Thomas: In your case, the problem is due to JAP. If you want to have quick startup time, you MUST get rid of JPA/JDO and use some other lightweight persistence api (Slim3, Objectify, Twig, ...) or use low level datastore api directly to access the datastore. Thanks for this important information, I will using Slim3 to do the same Counter testing again, thanks very much !!! -- 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.
