From: Oliver B. <ol...@g7...> - 2010-12-02 03:41:37
|
I recently installed Webware 1.1b on a new machine, and left it at its default Min/Start/MaxServerThreads (5/10/20) in webwarework/Configs/AppServer.config. I have observed that even when MinServerThreads are all busy, Webware is not starting new threads to handle new connections. Looking at the code, this seems to be because Webware decides how many threads it needs based on past activity; all threads being busy does not in itself trigger the creation of new threads. (I could be misunderstanding the code here.) I observed it using a simple Webware script that reports the number of active threads and roughly what they are doing. This script is normally very fast because it waits on no locks and does no database work. However when the server is busy I have occasionally noticed a several second delay before it returns, and when it does return I see that the other threads are all busy, and that the number of threads is still just 5. In fact, the number of threads is /always/ just 5, so far as I can see. Perhaps it is just that my requests come in a bad pattern: I observe that most of the Webware threads are idle most of the time, but occasionally a bunch of requests will come in together, and slow each other down trying to update the same table. As they wait, others pile in until the database clears the backlog and everyone is finished. I have fixed my problem by upping MinServerThreads to 20. I also noticed that I had MinServerThreads set to 100 on my old machine (Webware 0.8.1 or thereabouts), courtesy of an incident a few years ago when some of my threads were locking up, so I suspect what I am observing is not new. So my question is: is this behaviour normal? Am I handling this the right way? Oliver |
From: Christoph Z. <ci...@on...> - 2010-12-04 01:40:16
|
Am 02.12.2010 04:14 schrieb Oliver Bock: > I observed it using a simple Webware script that reports the number of > active threads and roughly what they are doing. This script is normally > very fast because it waits on no locks and does no database work. > However when the server is busy I have occasionally noticed a several > second delay before it returns, and when it does return I see that the > other threads are all busy, and that the number of threads is still just > 5. In fact, the number of threads is /always/ just 5, so far as I can see. > > So my question is: is this behaviour normal? Am I handling this the > right way? Hi Oliver, just looked into this. Webware comes with a servlet called "ThreadControl" in the Admin context. There you can see which threads are currently handling which requests, and how many threads are idle. When I start the appserver, it shows the thread handling the ThreadControl servlet, and 9 idle threads, as expected. Then after a while, the idle threads go down to 4, also as expected. Webware also also comes with a script "stress.py" in WebKit/Test/stress. After I tried a "stress.py 500 30 30", I saw 19 idle threads, slowly phasing down to 4 again, again just as expected. Can you try the same on your machine and check if you get the same behavior? -- Christoph |
From: Oliver B. <ol...@g7...> - 2010-12-21 01:48:58
|
On 4/12/2010 12:40 PM, Christoph Zwerschke wrote: > Am 02.12.2010 04:14 schrieb Oliver Bock: >> I observed it using a simple Webware script that reports the number of >> active threads and roughly what they are doing. This script is normally >> very fast because it waits on no locks and does no database work. >> However when the server is busy I have occasionally noticed a several >> second delay before it returns, and when it does return I see that the >> other threads are all busy, and that the number of threads is still just >> 5. In fact, the number of threads is /always/ just 5, so far as I can see. >> >> So my question is: is this behaviour normal? Am I handling this the >> right way? > Hi Oliver, just looked into this. > > Webware comes with a servlet called "ThreadControl" in the Admin > context. There you can see which threads are currently handling which > requests, and how many threads are idle. When I start the appserver, it > shows the thread handling the ThreadControl servlet, and 9 idle threads, > as expected. Then after a while, the idle threads go down to 4, also as > expected. Webware also also comes with a script "stress.py" in > WebKit/Test/stress. After I tried a "stress.py 500 30 30", I saw 19 idle > threads, slowly phasing down to 4 again, again just as expected. > > Can you try the same on your machine and check if you get the same behavior? Hi Cristoph, Thanks for your response, and sorry for the slow reply. I was at the beach :-) When I used stress.py I found that Webware is so fast on my server that it rarely required more than 5 threads, to run the pages requested, even when stress.py is running 300 "simultaneous" requests. To better simulate my problem I created a test page that contains a time.sleep(1), and then I found that after a second or two, Webware created many extra threads to handle the parallel requests. I could observe this both in my homegrown thread display script (mentioned originally) and in ThreadControl. This test was performed on the same production machine on which I originally observed the problem, so the only difference is the servlets being run, which should not affect AppServer's threading strategy! So I do not know what to think. I will look at ThreadControl if I observe the problem again. Regards, Oliver P.S: Perhaps this text could be added to the comment at the top of stress.py: Ensure that Examples is the default context and that your the hostname and port for your WebKit instance is in ../../adapter.address ("localhost:8090" is the default). |