[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
Hi Adligo, On Thu, Sep 10, 2009 at 6:15 PM, Adligo sc...@adligo.com wrote: Hi All, Ok this is all very interesting, and in a nut shell GAE isn't true J2EE impl. So now I am wondering; Is there a way to tell if my servlet is running on GAE? As far as I'm aware, the J2EE specification doesn't provide any guidelines for supporting 'hanging gets' or minimum/maximum request durations. This may seem like a really stupid question, however if you think about it a little from my point of view IT's NOT. The reason I am asking it is because I am trying to write Components (Server and Client [browser] side), which are for sale. So I may not be the one installing some of these Components, and it would be nice if the Component could simply figure out if it was running on GAE. Otherwise I will need to put some configuration settings in place; Something like web.xml isGae=true isGae=false I can tell you how to do this in Python (check the 'SERVER_SOFTWARE' environment variable), but I'm not familiar with how to check it in Java. You're probably better off asking this on the google-appengine-java group. -Nick Johnson Cheers, Scott On Sep 9, 5:24 am, Nick Johnson (Google) nick.john...@google.com wrote: Hi Adligo, On Tue, Sep 8, 2009 at 6:39 PM, Adligo sc...@adligo.com wrote: Hi Nick, Please see below; On Sep 4, 10:04 am, Nick Johnson (Google) nick.john...@google.com wrote: Hi Adligo, App Engine is not really designed for 'long polling' setups like you describe. Since the number of simultaneous runtimes your app has at a given traffic level is limited, waiting like this will consume them all very quickly. I understand this, which is why I was asking if you could pay for more. So can you? No. As stated, this is not something App Engine is designed to support, and thus your number of concurrent requests is limited proportional to the traffic your app gets. Also, because your app may be distributed over many computers, a synchronization primitive like the one you're using will not work - the process doing the notifying may not be on the same machine as the process(es) that need notifying! Well this depends a little on Session management, the ArrayBlockingQueue I mentioned is stored as a Session Attribute. I assume that the app engine must be keeping the Session in a location that can be accessed by all threads. Otherwise how could anyone maintain any sort or security on the server side (most Jaas HttpFilters I have seen store the Subject[User] as a Session Attribute, including 2 that I wrote by hand for custom requirements and Spring security) ? The issue is not multiple threads on one runtime, but the fact that a single App Engine app may be running on multiple runtimes, on multiple separate machines. You cannot expect a standard locking primitive to function across multiple machines. Or in other words how does the app engine treat HttpSessions and their attributes, in the normal J2EE way, or some other way? Sessions are stored in the datastore. -Nick Johnson Cheers, Scott -Nick Johnson On Thu, Sep 3, 2009 at 9:06 PM, Adligo sc...@adligo.com wrote: Hi Nick, I am not calling sleep but I am using a server side ArrayBlockingQueue, with methods like queue.poll(waitTime, TimeUnit.SECONDS); So I am not buffering but simply responding with current messages and if there arn't any waiting until some show up and then responding. If no messages show up in 20 seconds or so I respond with a empty message list and then the client sends a new request. I am using GWT's rpc, here is my service api, which is open souce. http://cvs.adligo.org/viewvc/gwt_util/src/org/adligo/gwt/util/client/. .. So I am anticipateing that I will have a lot of threads that are simply waiting on the ArrayBlockingQueue's poll method. This allows me to do things like; 1) send log messages between two browser windows 2) send system messages from a admin console to anyone viewing the app like; (System is going off line in 10 minutes) (There is pizza in the lobby for anyone who wants it) exc 3) Implement a IM client in the browser 4) Send 'event' data between browser windows so a user can click a button in one window and have it do something to another window. Currently the only application of this is to reload the adligo_log.properties file, so you can change your log levels at runtime. However there are a lot of other applications for this, windows can now communicate. Also there shouldn't be much of a drain on the processor, since most of the threads are simply waiting (not doing a lot of processing). It just requires a large
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
Hi All, Ok this is all very interesting, and in a nut shell GAE isn't true J2EE impl. So now I am wondering; Is there a way to tell if my servlet is running on GAE? This may seem like a really stupid question, however if you think about it a little from my point of view IT's NOT. The reason I am asking it is because I am trying to write Components (Server and Client [browser] side), which are for sale. So I may not be the one installing some of these Components, and it would be nice if the Component could simply figure out if it was running on GAE. Otherwise I will need to put some configuration settings in place; Something like web.xml isGae=true isGae=false Cheers, Scott On Sep 9, 5:24 am, Nick Johnson (Google) nick.john...@google.com wrote: Hi Adligo, On Tue, Sep 8, 2009 at 6:39 PM, Adligo sc...@adligo.com wrote: Hi Nick, Please see below; On Sep 4, 10:04 am, Nick Johnson (Google) nick.john...@google.com wrote: Hi Adligo, App Engine is not really designed for 'long polling' setups like you describe. Since the number of simultaneous runtimes your app has at a given traffic level is limited, waiting like this will consume them all very quickly. I understand this, which is why I was asking if you could pay for more. So can you? No. As stated, this is not something App Engine is designed to support, and thus your number of concurrent requests is limited proportional to the traffic your app gets. Also, because your app may be distributed over many computers, a synchronization primitive like the one you're using will not work - the process doing the notifying may not be on the same machine as the process(es) that need notifying! Well this depends a little on Session management, the ArrayBlockingQueue I mentioned is stored as a Session Attribute. I assume that the app engine must be keeping the Session in a location that can be accessed by all threads. Otherwise how could anyone maintain any sort or security on the server side (most Jaas HttpFilters I have seen store the Subject[User] as a Session Attribute, including 2 that I wrote by hand for custom requirements and Spring security) ? The issue is not multiple threads on one runtime, but the fact that a single App Engine app may be running on multiple runtimes, on multiple separate machines. You cannot expect a standard locking primitive to function across multiple machines. Or in other words how does the app engine treat HttpSessions and their attributes, in the normal J2EE way, or some other way? Sessions are stored in the datastore. -Nick Johnson Cheers, Scott -Nick Johnson On Thu, Sep 3, 2009 at 9:06 PM, Adligo sc...@adligo.com wrote: Hi Nick, I am not calling sleep but I am using a server side ArrayBlockingQueue, with methods like queue.poll(waitTime, TimeUnit.SECONDS); So I am not buffering but simply responding with current messages and if there arn't any waiting until some show up and then responding. If no messages show up in 20 seconds or so I respond with a empty message list and then the client sends a new request. I am using GWT's rpc, here is my service api, which is open souce. http://cvs.adligo.org/viewvc/gwt_util/src/org/adligo/gwt/util/client/. .. So I am anticipateing that I will have a lot of threads that are simply waiting on the ArrayBlockingQueue's poll method. This allows me to do things like; 1) send log messages between two browser windows 2) send system messages from a admin console to anyone viewing the app like; (System is going off line in 10 minutes) (There is pizza in the lobby for anyone who wants it) exc 3) Implement a IM client in the browser 4) Send 'event' data between browser windows so a user can click a button in one window and have it do something to another window. Currently the only application of this is to reload the adligo_log.properties file, so you can change your log levels at runtime. However there are a lot of other applications for this, windows can now communicate. Also there shouldn't be much of a drain on the processor, since most of the threads are simply waiting (not doing a lot of processing). It just requires a large number of threads (one per browser window). Cheers, Scott PS I would really like to host on Google Apps, the server http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true was down all morning, since I had my phone turned off to respect for a concert last night I didn't get a 'your server is down' text from hosttracker.com. On Sep 3, 3:51 am, Nick Johnson (Google) nick.john...@google.com wrote: Hi Adligo, The limit on concurrent instances of your app is not a hard one - it will increase as your app gets more traffic. The
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
Hi Adligo, On Tue, Sep 8, 2009 at 6:39 PM, Adligo sc...@adligo.com wrote: Hi Nick, Please see below; On Sep 4, 10:04 am, Nick Johnson (Google) nick.john...@google.com wrote: Hi Adligo, App Engine is not really designed for 'long polling' setups like you describe. Since the number of simultaneous runtimes your app has at a given traffic level is limited, waiting like this will consume them all very quickly. I understand this, which is why I was asking if you could pay for more. So can you? No. As stated, this is not something App Engine is designed to support, and thus your number of concurrent requests is limited proportional to the traffic your app gets. Also, because your app may be distributed over many computers, a synchronization primitive like the one you're using will not work - the process doing the notifying may not be on the same machine as the process(es) that need notifying! Well this depends a little on Session management, the ArrayBlockingQueue I mentioned is stored as a Session Attribute. I assume that the app engine must be keeping the Session in a location that can be accessed by all threads. Otherwise how could anyone maintain any sort or security on the server side (most Jaas HttpFilters I have seen store the Subject[User] as a Session Attribute, including 2 that I wrote by hand for custom requirements and Spring security) ? The issue is not multiple threads on one runtime, but the fact that a single App Engine app may be running on multiple runtimes, on multiple separate machines. You cannot expect a standard locking primitive to function across multiple machines. Or in other words how does the app engine treat HttpSessions and their attributes, in the normal J2EE way, or some other way? Sessions are stored in the datastore. -Nick Johnson Cheers, Scott -Nick Johnson On Thu, Sep 3, 2009 at 9:06 PM, Adligo sc...@adligo.com wrote: Hi Nick, I am not calling sleep but I am using a server side ArrayBlockingQueue, with methods like queue.poll(waitTime, TimeUnit.SECONDS); So I am not buffering but simply responding with current messages and if there arn't any waiting until some show up and then responding. If no messages show up in 20 seconds or so I respond with a empty message list and then the client sends a new request. I am using GWT's rpc, here is my service api, which is open souce. http://cvs.adligo.org/viewvc/gwt_util/src/org/adligo/gwt/util/client/. .. So I am anticipateing that I will have a lot of threads that are simply waiting on the ArrayBlockingQueue's poll method. This allows me to do things like; 1) send log messages between two browser windows 2) send system messages from a admin console to anyone viewing the app like; (System is going off line in 10 minutes) (There is pizza in the lobby for anyone who wants it) exc 3) Implement a IM client in the browser 4) Send 'event' data between browser windows so a user can click a button in one window and have it do something to another window. Currently the only application of this is to reload the adligo_log.properties file, so you can change your log levels at runtime. However there are a lot of other applications for this, windows can now communicate. Also there shouldn't be much of a drain on the processor, since most of the threads are simply waiting (not doing a lot of processing). It just requires a large number of threads (one per browser window). Cheers, Scott PS I would really like to host on Google Apps, the server http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true was down all morning, since I had my phone turned off to respect for a concert last night I didn't get a 'your server is down' text from hosttracker.com. On Sep 3, 3:51 am, Nick Johnson (Google) nick.john...@google.com wrote: Hi Adligo, The limit on concurrent instances of your app is not a hard one - it will increase as your app gets more traffic. The only situation you're likely to run into it is if you have a lot of requests that take a long time to complete - eg, if you're calling time.sleep() in your request handler. As long as you're serving your requests reasonably efficiently, you can expect the number of concurrent requests your app is allowed to scale up with load. -Nick Johnson On Wed, Sep 2, 2009 at 1:33 AM, Adligo sc...@adligo.com wrote: Hi, I am developing a app (or more than one) that I would like to host on Google App Engine, however the architecture of the app involves cranking up the maxThreads (I am using my home grown hosting which now has Tomcat set to 2,000 maxThreads :) ). For example (1 six+ year old machine in my basement)
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
Hi Nick, Please see below; On Sep 4, 10:04 am, Nick Johnson (Google) nick.john...@google.com wrote: Hi Adligo, App Engine is not really designed for 'long polling' setups like you describe. Since the number of simultaneous runtimes your app has at a given traffic level is limited, waiting like this will consume them all very quickly. I understand this, which is why I was asking if you could pay for more. So can you? Also, because your app may be distributed over many computers, a synchronization primitive like the one you're using will not work - the process doing the notifying may not be on the same machine as the process(es) that need notifying! Well this depends a little on Session management, the ArrayBlockingQueue I mentioned is stored as a Session Attribute. I assume that the app engine must be keeping the Session in a location that can be accessed by all threads. Otherwise how could anyone maintain any sort or security on the server side (most Jaas HttpFilters I have seen store the Subject[User] as a Session Attribute, including 2 that I wrote by hand for custom requirements and Spring security) ? Or in other words how does the app engine treat HttpSessions and their attributes, in the normal J2EE way, or some other way? Cheers, Scott -Nick Johnson On Thu, Sep 3, 2009 at 9:06 PM, Adligo sc...@adligo.com wrote: Hi Nick, I am not calling sleep but I am using a server side ArrayBlockingQueue, with methods like queue.poll(waitTime, TimeUnit.SECONDS); So I am not buffering but simply responding with current messages and if there arn't any waiting until some show up and then responding. If no messages show up in 20 seconds or so I respond with a empty message list and then the client sends a new request. I am using GWT's rpc, here is my service api, which is open souce. http://cvs.adligo.org/viewvc/gwt_util/src/org/adligo/gwt/util/client/... So I am anticipateing that I will have a lot of threads that are simply waiting on the ArrayBlockingQueue's poll method. This allows me to do things like; 1) send log messages between two browser windows 2) send system messages from a admin console to anyone viewing the app like; (System is going off line in 10 minutes) (There is pizza in the lobby for anyone who wants it) exc 3) Implement a IM client in the browser 4) Send 'event' data between browser windows so a user can click a button in one window and have it do something to another window. Currently the only application of this is to reload the adligo_log.properties file, so you can change your log levels at runtime. However there are a lot of other applications for this, windows can now communicate. Also there shouldn't be much of a drain on the processor, since most of the threads are simply waiting (not doing a lot of processing). It just requires a large number of threads (one per browser window). Cheers, Scott PS I would really like to host on Google Apps, the server http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true was down all morning, since I had my phone turned off to respect for a concert last night I didn't get a 'your server is down' text from hosttracker.com. On Sep 3, 3:51 am, Nick Johnson (Google) nick.john...@google.com wrote: Hi Adligo, The limit on concurrent instances of your app is not a hard one - it will increase as your app gets more traffic. The only situation you're likely to run into it is if you have a lot of requests that take a long time to complete - eg, if you're calling time.sleep() in your request handler. As long as you're serving your requests reasonably efficiently, you can expect the number of concurrent requests your app is allowed to scale up with load. -Nick Johnson On Wed, Sep 2, 2009 at 1:33 AM, Adligo sc...@adligo.com wrote: Hi, I am developing a app (or more than one) that I would like to host on Google App Engine, however the architecture of the app involves cranking up the maxThreads (I am using my home grown hosting which now has Tomcat set to 2,000 maxThreads :) ). For example (1 six+ year old machine in my basement) http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true I was reading somewhere that my app will be limited to 30 Max simultaneous requests (maxThreads), and I didn't see anything about being able to change this (EVEN IF YOU PAY FOR IT). So is it possible to change this? If not why, it should be billable like everything else... How much would it cost? Also I think that it seems like a silly limit (although probably a good starting point for most apps). Some apps need a lot of threads, some have a lot of page requests. For instance my app needs a lot of threads (the above version uses at least 1 per user ALL THE TIME) and will go to 2 per user in the
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adligo wrote: [...] I mentioned is stored as a Session Attribute. I assume that the app engine must be keeping the Session in a location that can be accessed by all threads. I'm afraid not! The *only* mechanism for communicating between requests is, AFAIK (and if I'm wrong someone please correct me), memcache or the datastore. Any request may be hosted in any servlet on any JVM on any machine in any datacentre in any continent, and you can't rely on any two requests running in the same place. (Or on the moon in the Google moonbase, but given the latency that would be unlikely.) AppEngine is perfectly entitled to run your code anywhere it feels like, although it's probably going to run it close to the data. Otherwise how could anyone maintain any sort or security on the server side (most Jaas HttpFilters I have seen store the Subject[User] as a Session Attribute, including 2 that I wrote by hand for custom requirements and Spring security) ? AppEngine does implement servlet sessions, but it's just a wrapper around the datastore --- it will automatically save your session objects and reload them for you. I don't believe it's defined when this happens, though, so you probably can't change properties in one session and rely on being able to see them change in another in real time. Personally, I find it easiest if I just forget everything I ever knew about servlets and start again from scratch when dealing with AppEngine. It's sufficiently strange not to be able to take anything for granted. (People here are most likely already tired of my rants about not being able to synchronise between threads...) - -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ People who think they know everything really annoy those of us who │ know we don't. --- Bjarne Stroustrup -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKprdKf9E0noFvlzgRAu3bAJ9/hEJSHlsaluusBljVRZyz/QF4HQCguPKw 2kt1/NVlqrU/T84idi6h11I= =3mR2 -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
On Sep 8, 2:58 pm, David Given d...@cowlark.com wrote: Adligo wrote: I mentioned is stored as a Session Attribute. I assume that the app engine must be keeping the Session in a location that can be accessed by all threads. I'm afraid not! The *only* mechanism for communicating between requests is, AFAIK (and if I'm wrong someone please correct me), memcache or the datastore. Actually, you can also use the URLFetch service to make callbacks to your application, thereby providing a thread a way to talk to another thread. This is used to good effect to parallelize queries in the asynctools project, http://code.google.com/p/asynctools/. blatant promotion of self interest Unfortunately, the Java API does not support async URLFetch like the Python API. Please go vote for async URLFetch in Java here... http://code.google.com/p/googleappengine/issues/detail?id=1899q=emorningcolspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Summary%20Log%20Component /blatant promotion of self interest --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
Hi Adligo, App Engine is not really designed for 'long polling' setups like you describe. Since the number of simultaneous runtimes your app has at a given traffic level is limited, waiting like this will consume them all very quickly. Also, because your app may be distributed over many computers, a synchronization primitive like the one you're using will not work - the process doing the notifying may not be on the same machine as the process(es) that need notifying! -Nick Johnson On Thu, Sep 3, 2009 at 9:06 PM, Adligo sc...@adligo.com wrote: Hi Nick, I am not calling sleep but I am using a server side ArrayBlockingQueue, with methods like queue.poll(waitTime, TimeUnit.SECONDS); So I am not buffering but simply responding with current messages and if there arn't any waiting until some show up and then responding. If no messages show up in 20 seconds or so I respond with a empty message list and then the client sends a new request. I am using GWT's rpc, here is my service api, which is open souce. http://cvs.adligo.org/viewvc/gwt_util/src/org/adligo/gwt/util/client/rpc/MessageService.java?view=markup So I am anticipateing that I will have a lot of threads that are simply waiting on the ArrayBlockingQueue's poll method. This allows me to do things like; 1) send log messages between two browser windows 2) send system messages from a admin console to anyone viewing the app like; (System is going off line in 10 minutes) (There is pizza in the lobby for anyone who wants it) exc 3) Implement a IM client in the browser 4) Send 'event' data between browser windows so a user can click a button in one window and have it do something to another window. Currently the only application of this is to reload the adligo_log.properties file, so you can change your log levels at runtime. However there are a lot of other applications for this, windows can now communicate. Also there shouldn't be much of a drain on the processor, since most of the threads are simply waiting (not doing a lot of processing). It just requires a large number of threads (one per browser window). Cheers, Scott PS I would really like to host on Google Apps, the server http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true was down all morning, since I had my phone turned off to respect for a concert last night I didn't get a 'your server is down' text from hosttracker.com. On Sep 3, 3:51 am, Nick Johnson (Google) nick.john...@google.com wrote: Hi Adligo, The limit on concurrent instances of your app is not a hard one - it will increase as your app gets more traffic. The only situation you're likely to run into it is if you have a lot of requests that take a long time to complete - eg, if you're calling time.sleep() in your request handler. As long as you're serving your requests reasonably efficiently, you can expect the number of concurrent requests your app is allowed to scale up with load. -Nick Johnson On Wed, Sep 2, 2009 at 1:33 AM, Adligo sc...@adligo.com wrote: Hi, I am developing a app (or more than one) that I would like to host on Google App Engine, however the architecture of the app involves cranking up the maxThreads (I am using my home grown hosting which now has Tomcat set to 2,000 maxThreads :) ). For example (1 six+ year old machine in my basement) http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true I was reading somewhere that my app will be limited to 30 Max simultaneous requests (maxThreads), and I didn't see anything about being able to change this (EVEN IF YOU PAY FOR IT). So is it possible to change this? If not why, it should be billable like everything else... How much would it cost? Also I think that it seems like a silly limit (although probably a good starting point for most apps). Some apps need a lot of threads, some have a lot of page requests. For instance my app needs a lot of threads (the above version uses at least 1 per user ALL THE TIME) and will go to 2 per user in the next release :) Or rather to be more specific One thread per open browser window, so I can 'send' data to the browser window in near real time with out having the browser window send a request every millisecond (which causes other problems). So it will be limited to 15 users on Googles App Engine yikes! Cheers, Scott -- Nick Johnson, Developer Programs Engineer, App Engine- Hide quoted text - - Show quoted text - -- Nick Johnson, Developer Programs Engineer, App Engine --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
Hi Adligo, The limit on concurrent instances of your app is not a hard one - it will increase as your app gets more traffic. The only situation you're likely to run into it is if you have a lot of requests that take a long time to complete - eg, if you're calling time.sleep() in your request handler. As long as you're serving your requests reasonably efficiently, you can expect the number of concurrent requests your app is allowed to scale up with load. -Nick Johnson On Wed, Sep 2, 2009 at 1:33 AM, Adligo sc...@adligo.com wrote: Hi, I am developing a app (or more than one) that I would like to host on Google App Engine, however the architecture of the app involves cranking up the maxThreads (I am using my home grown hosting which now has Tomcat set to 2,000 maxThreads :) ). For example (1 six+ year old machine in my basement) http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true I was reading somewhere that my app will be limited to 30 Max simultaneous requests (maxThreads), and I didn't see anything about being able to change this (EVEN IF YOU PAY FOR IT). So is it possible to change this? If not why, it should be billable like everything else... How much would it cost? Also I think that it seems like a silly limit (although probably a good starting point for most apps). Some apps need a lot of threads, some have a lot of page requests. For instance my app needs a lot of threads (the above version uses at least 1 per user ALL THE TIME) and will go to 2 per user in the next release :) Or rather to be more specific One thread per open browser window, so I can 'send' data to the browser window in near real time with out having the browser window send a request every millisecond (which causes other problems). So it will be limited to 15 users on Googles App Engine yikes! Cheers, Scott -- Nick Johnson, Developer Programs Engineer, App Engine --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
Hi Nick, I am not calling sleep but I am using a server side ArrayBlockingQueue, with methods like queue.poll(waitTime, TimeUnit.SECONDS); So I am not buffering but simply responding with current messages and if there arn't any waiting until some show up and then responding. If no messages show up in 20 seconds or so I respond with a empty message list and then the client sends a new request. I am using GWT's rpc, here is my service api, which is open souce. http://cvs.adligo.org/viewvc/gwt_util/src/org/adligo/gwt/util/client/rpc/MessageService.java?view=markup So I am anticipateing that I will have a lot of threads that are simply waiting on the ArrayBlockingQueue's poll method. This allows me to do things like; 1) send log messages between two browser windows 2) send system messages from a admin console to anyone viewing the app like; (System is going off line in 10 minutes) (There is pizza in the lobby for anyone who wants it) exc 3) Implement a IM client in the browser 4) Send 'event' data between browser windows so a user can click a button in one window and have it do something to another window. Currently the only application of this is to reload the adligo_log.properties file, so you can change your log levels at runtime. However there are a lot of other applications for this, windows can now communicate. Also there shouldn't be much of a drain on the processor, since most of the threads are simply waiting (not doing a lot of processing). It just requires a large number of threads (one per browser window). Cheers, Scott PS I would really like to host on Google Apps, the server http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true was down all morning, since I had my phone turned off to respect for a concert last night I didn't get a 'your server is down' text from hosttracker.com. On Sep 3, 3:51 am, Nick Johnson (Google) nick.john...@google.com wrote: Hi Adligo, The limit on concurrent instances of your app is not a hard one - it will increase as your app gets more traffic. The only situation you're likely to run into it is if you have a lot of requests that take a long time to complete - eg, if you're calling time.sleep() in your request handler. As long as you're serving your requests reasonably efficiently, you can expect the number of concurrent requests your app is allowed to scale up with load. -Nick Johnson On Wed, Sep 2, 2009 at 1:33 AM, Adligo sc...@adligo.com wrote: Hi, I am developing a app (or more than one) that I would like to host on Google App Engine, however the architecture of the app involves cranking up the maxThreads (I am using my home grown hosting which now has Tomcat set to 2,000 maxThreads :) ). For example (1 six+ year old machine in my basement) http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true I was reading somewhere that my app will be limited to 30 Max simultaneous requests (maxThreads), and I didn't see anything about being able to change this (EVEN IF YOU PAY FOR IT). So is it possible to change this? If not why, it should be billable like everything else... How much would it cost? Also I think that it seems like a silly limit (although probably a good starting point for most apps). Some apps need a lot of threads, some have a lot of page requests. For instance my app needs a lot of threads (the above version uses at least 1 per user ALL THE TIME) and will go to 2 per user in the next release :) Or rather to be more specific One thread per open browser window, so I can 'send' data to the browser window in near real time with out having the browser window send a request every millisecond (which causes other problems). So it will be limited to 15 users on Googles App Engine yikes! Cheers, Scott -- Nick Johnson, Developer Programs Engineer, App Engine- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
What would you need all those threads for in a web App? If you were crunching DNA, or calculating the path of particles from the big bang that would make sense... But if your App completes a request in less than 3 seconds, you would still be able to server 10 users a second, 600 users a minute, 864k requests a day. If having 3 threads sped this up to 1 second, the math would work out to the same number of request potentials. Do to the CPU time limits on a task, it is unlikely you would want 2000 threads because you'd burn through your Cycle limit just setting up those threads. I'm assuming from the Smiley after your comment about Cranking up the max threads, that you THINK you are doing something clever. In all likely unless you are doing some super computing apps on a CPU(s) with enough cores to support that number of threads you are just wasting cycles in thread management, and time slicing. -Brandon Wirtz -Original Message- From: google-appengine@googlegroups.com [mailto:google-appeng...@googlegroups.com] On Behalf Of Adligo Sent: Tuesday, September 01, 2009 5:34 PM To: Google App Engine Subject: [google-appengine] 30 Max simultaneous requests (maxThreads)? Hi, I am developing a app (or more than one) that I would like to host on Google App Engine, however the architecture of the app involves cranking up the maxThreads (I am using my home grown hosting which now has Tomcat set to 2,000 maxThreads :) ). For example (1 six+ year old machine in my basement) http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
There are application domains that spike severely. One example is AAA for corporate environments. There are large companies on the planet where *everyone* comes to work @ 8am +/-10min and logs in. Just one example from a prior life... On Wed, Sep 2, 2009 at 12:34 PM, Brandon N. Wirtzdrak...@digerat.com wrote: What would you need all those threads for in a web App? If you were crunching DNA, or calculating the path of particles from the big bang that would make sense... But if your App completes a request in less than 3 seconds, you would still be able to server 10 users a second, 600 users a minute, 864k requests a day. If having 3 threads sped this up to 1 second, the math would work out to the same number of request potentials. Do to the CPU time limits on a task, it is unlikely you would want 2000 threads because you'd burn through your Cycle limit just setting up those threads. I'm assuming from the Smiley after your comment about Cranking up the max threads, that you THINK you are doing something clever. In all likely unless you are doing some super computing apps on a CPU(s) with enough cores to support that number of threads you are just wasting cycles in thread management, and time slicing. -Brandon Wirtz -Original Message- From: google-appengine@googlegroups.com [mailto:google-appeng...@googlegroups.com] On Behalf Of Adligo Sent: Tuesday, September 01, 2009 5:34 PM To: Google App Engine Subject: [google-appengine] 30 Max simultaneous requests (maxThreads)? Hi, I am developing a app (or more than one) that I would like to host on Google App Engine, however the architecture of the app involves cranking up the maxThreads (I am using my home grown hosting which now has Tomcat set to 2,000 maxThreads :) ). For example (1 six+ year old machine in my basement) http://zeuhl.adligo.com/gwt_util_demo_v3_1/GwtDemo.html?show_log=true --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
On Sep 2, 2:34 pm, Brandon N. Wirtz drak...@digerat.com wrote: What would you need all those threads for in a web App? If you were crunching DNA, or calculating the path of particles from the big bang that would make sense... When you make an asynchronous URLFetch call does each asynchronous call to URLFetch count as a separate thread??? Suppose I want to write an app that will aggregate the search results from 30 different search engines (that's not an unrealistic real-life scenario, lots of things have to be done asynchrounously). Suppose each call to a search engine takes 1 second. Suppose I make 30 aynchronous calls to each search engine. It'll take 2 seconds for each request (cause I blew pass my thread limit on the 30th async call so I'll have to wait an extra second for that last request). And now I can only handle one user every second. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
And there is a form you can fill out to have your request per second limit increased if that is a need. http://code.google.com/support/bin/request.py?contact_type=AppEngineCPUReque st Just explain why you need more resources and they will be granted. Even 100k people showing up with in a 5 minute time frame is only 333 requests a second. You should have a hard time hitting the 500 QPQ limit. Also you can round robin portions of your cycles by putting a request proxy ahead of your large app so that you are less restricted by these already generous limits. Is anyone actually hitting Thread limit errors? Or is this just a typical I'm going to be the next Facebook OMG Google won't work for this when I get to 1.2m active users guess I should build my own server in my basement because it will be better, sort of naval gazing that I face with PMs and SysArc's on a regular basis? You can't break the speed of light with a Jet Engine either, but its still over kill for my soapbox derby car. -Brandon Wirtz -Original Message- From: google-appengine@googlegroups.com [mailto:google-appeng...@googlegroups.com] On Behalf Of Jeff Enderwick Sent: Wednesday, September 02, 2009 12:40 PM To: google-appengine@googlegroups.com Subject: [google-appengine] Re: 30 Max simultaneous requests (maxThreads)? There are application domains that spike severely. One example is AAA for corporate environments. There are large companies on the planet where *everyone* comes to work @ 8am +/-10min and logs in. Just one example from a prior life... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
I'm not sure that would be acceptable in the Terms of Most Search engines... And many of the search engines are likely going to start blocking GAE traffic... But for arguments sake let's say you are using API's and it was allowed. Because you are building say a Price Engine powered by Amazon and Buy.com and 28 others. I have done a similar project already. Caching. 80% of your queries will be for 20% of the terms as such new queries will take 2 seconds (your number), old queries will take 85ms. With 80% cache hit you will have an average page served time of 468ms. To reduce this you would do predictive searches. (Crawling :-) ) Precaching terms you expect to see. Which could take you to 95% cache hits and closer to 90ms average response time. -Brandon Wirtz -Original Message- From: google-appengine@googlegroups.com [mailto:google-appeng...@googlegroups.com] On Behalf Of ted stockwell Sent: Wednesday, September 02, 2009 1:59 PM To: Google App Engine Subject: [google-appengine] Re: 30 Max simultaneous requests (maxThreads)? On Sep 2, 2:34 pm, Brandon N. Wirtz drak...@digerat.com wrote: What would you need all those threads for in a web App? If you were crunching DNA, or calculating the path of particles from the big bang that would make sense... When you make an asynchronous URLFetch call does each asynchronous call to URLFetch count as a separate thread??? Suppose I want to write an app that will aggregate the search results from 30 different search engines (that's not an unrealistic real-life scenario, lots of things have to be done asynchrounously). Suppose each call to a search engine takes 1 second. Suppose I make 30 aynchronous calls to each search engine. It'll take 2 seconds for each request (cause I blew pass my thread limit on the 30th async call so I'll have to wait an extra second for that last request). And now I can only handle one user every second. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: 30 Max simultaneous requests (maxThreads)?
On Sep 2, 4:25 pm, Brandon N. Wirtz drak...@digerat.com wrote: Is anyone actually hitting Thread limit errors? Or is this just a typical I'm going to be the next Facebook OMG Google won't work for this when I get to 1.2m active users guess I should build my own server in my basement because it will be better, sort of naval gazing that I face with PMs and SysArc's on a regular basis? You can't break the speed of light with a Jet Engine either, but its still over kill for my soapbox derby car. Some engineers prefer to try to anticipate the problems they may run into rather than wait until the wings fall off their plane in midflight. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
