Re: JRUN Stability- reply 2
Kathy, we run primarily on windows.I have done some tests on linux, but not to this extent. Our app uses keepalive connections that remain open, so we need a very high level of concurrency.In production we run at 750 concurrent connections (users) per node.The JRun server doesn't seem to pre-allocate the threads, so they remain upper limits.We also run with a non-sanctioned patch provided by macromedia folks, because regular JRun will get stuck at 1000 activeHandlerThreads.They gave me the patch, but in followup email have been quiet to answer my request for info on when the change would be incorporated into the base code.I was working with someone by the name of Stephen Dupre last August; he was most helpful. Using the patch we have tested just beyond 1800 in our lab with the IBM jvm and 1700 with the sun jvm, before we run into memory management problems.We use the following jvm args now with sun 1.4: -Xms128m -Xmx128m -Xss64k In order to use such high settinmgs you also need to adjust your web server because by default they don't permit such high levels of concurrency either - I assume as a precaution against DOS attacks.So you have to adjust your Apache or IIS settings. If I recall my experiments properly, the jvm on windows is limited to 2048 threads, so to get beyond that on a single machine you need to have multiple vm's.So, I put several JRun servers under IIS, but then I started to run up against some upper limits of IIS.I never got further than 4000 concurrent connections for a single win2k box with 1 cpu, and that was with three JRun servers under IIS. Hope that helps, BenG. [EMAIL PROTECTED] wrote: Ben, How is the stability and performance of JRun server after you set activeHandlerThreads to 2000? Usually the number of the maxHandlerThreads should be bigger than activeHandlerThreads? As I understand, JRun would not perform well if the number of activeHandlerThreads is too big. Could you share your experience here? How busy would the traffic be on your site and is your site running in UNIX box? Thanks. Kathy --- Ben Groeneveld [EMAIL PROTECTED] wrote: This is true; to achieve high levels of concurrency we run with attribute name=activeHandlerThreads2000/attribute attribute name=maxHandlerThreads2000/attribute Hope that helps, BenG. [EMAIL PROTECTED] wrote: Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon -Original Message- From: Kathy Vance [mailto:[EMAIL PROTECTED] Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you need. Sometimes you could get the same error mentioned while using jsp forward tag. But I believe that Updater 3 may solve forwarding issue on JRun 4. for your info, Kathy --- Jon Austin [EMAIL PROTECTED] wrote: Thanks to all for their input on this topic, I am getting more resource directed to this in the next day or, so, and will be running through some of the troubleshooting tips given here. I understand that many of you are running successfully, with many concurrent users, the question now, I have for those people, is what kind of scope is your application? Are we simply talking glorified web-sites with a little processing behind them, or are we talking full hard-code business applications. Our application falls heavily on the latter, and before I base conclusions on other peoples abilities to produce results under this environment, I want to be sure that we're in the same ballpark. One error which a user did capture during a server-halt the other day, was : Too many concurrent requests, jcp.endpoint.main.max.threads exceeded. I found documents on how to resolve this on JRUN3.. but none of the files that are referenced in that document, exist on my JRUN4 implimenation.Does anyone know where I can find the new settings fro JRUN4. Thanks ~ Jon [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: JRUN Stability- reply 2
Hi Ben, You have to admit we were in some unexplored territory with that hotfix patch.(it's still being discussed). I don't think this applies to the general server hung issue Jon originally posted which is best handled by some of the debugging techniques mentioned by others (stack trace, etc) without changing the environment (JVMs, etc). Your app is very unique.It actually can have 750 concurrent, ACTIVE/RUNNING threads which doesn't resemble the typical web app of 10-20 possible request threads with maybe 5-10 active at any one time and constantly changing.I'm frankly amazed that you were able to tune it so well with JRun and find all those outer limitations of JVMs, etc that you mention. Stephen Dupre Macromedia QA -Original Message- From: Ben Groeneveld [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 1:12 PM To: JRun-Talk Subject: Re: JRUN Stability- reply 2 Kathy, we run primarily on windows.I have done some tests on linux, but not to this extent. Our app uses keepalive connections that remain open, so we need a very high level of concurrency.In production we run at 750 concurrent connections (users) per node.The JRun server doesn't seem to pre-allocate the threads, so they remain upper limits.We also run with a non-sanctioned patch provided by macromedia folks, because regular JRun will get stuck at 1000 activeHandlerThreads.They gave me the patch, but in followup email have been quiet to answer my request for info on when the change would be incorporated into the base code.I was working with someone by the name of Stephen Dupre last August; he was most helpful. Using the patch we have tested just beyond 1800 in our lab with the IBM jvm and 1700 with the sun jvm, before we run into memory management problems.We use the following jvm args now with sun 1.4: -Xms128m -Xmx128m -Xss64k In order to use such high settinmgs you also need to adjust your web server because by default they don't permit such high levels of concurrency either - I assume as a precaution against DOS attacks.So you have to adjust your Apache or IIS settings. If I recall my experiments properly, the jvm on windows is limited to 2048 threads, so to get beyond that on a single machine you need to have multiple vm's.So, I put several JRun servers under IIS, but then I started to run up against some upper limits of IIS.I never got further than 4000 concurrent connections for a single win2k box with 1 cpu, and that was with three JRun servers under IIS. Hope that helps, BenG. [EMAIL PROTECTED] wrote: Ben, How is the stability and performance of JRun server after you set activeHandlerThreads to 2000? Usually the number of the maxHandlerThreads should be bigger than activeHandlerThreads? As I understand, JRun would not perform well if the number of activeHandlerThreads is too big. Could you share your experience here? How busy would the traffic be on your site and is your site running in UNIX box? Thanks. Kathy --- Ben Groeneveld [EMAIL PROTECTED] wrote: This is true; to achieve high levels of concurrency we run with attribute name=activeHandlerThreads2000/attribute attribute name=maxHandlerThreads2000/attribute Hope that helps, BenG. [EMAIL PROTECTED] wrote: Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon -Original Message- From: Kathy Vance [mailto:[EMAIL PROTECTED] Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you need. Sometimes you could get the same error mentioned while using jsp forward tag. But I believe that Updater 3 may solve forwarding issue on JRun 4. for your info, Kathy --- Jon Austin [EMAIL PROTECTED] wrote: Thanks to all for their input on this topic, I am getting more resource directed to this in the next day or, so, and will be running through some of the troubleshooting tips given here. I understand that many of you are running successfully, with many concurrent users, the question now, I have for those people, is what kind of scope is your application? Are we simply talking glorified web-sites with a little processing behind them, or are we
Re: JRUN Stability- reply 2
[EMAIL PROTECTED] wrote: Hi Ben, You have to admit we were in some unexplored territory with that hotfix patch.(it's still being discussed). I don't think this applies to the general server hung issue Jon originally posted which is best handled by some of the debugging techniques mentioned by others (stack trace, etc) without changing the environment (JVMs, etc). Your app is very unique.It actually can have 750 concurrent, ACTIVE/RUNNING threads which doesn't resemble the typical web app of 10-20 possible request threads with maybe 5-10 active at any one time and constantly changing.I'm frankly amazed that you were able to tune it so well with JRun and find all those outer limitations of JVMs, etc that you mention. Well of course that is the beauty of our profession - we are all writing unique apps.I hope you didn't find this email on a negative note.I am most appreciative of your help.It's just the absense of a response that puzzled me.Thanks, BenG. Stephen Dupre Macromedia QA -Original Message- From: Ben Groeneveld [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 1:12 PM To: JRun-Talk Subject: Re: JRUN Stability- reply 2 Kathy, we run primarily on windows.I have done some tests on linux, but not to this extent. Our app uses keepalive connections that remain open, so we need a very high level of concurrency.In production we run at 750 concurrent connections (users) per node.The JRun server doesn't seem to pre-allocate the threads, so they remain upper limits.We also run with a non-sanctioned patch provided by macromedia folks, because regular JRun will get stuck at 1000 activeHandlerThreads.They gave me the patch, but in followup email have been quiet to answer my request for info on when the change would be incorporated into the base code.I was working with someone by the name of Stephen Dupre last August; he was most helpful. Using the patch we have tested just beyond 1800 in our lab with the IBM jvm and 1700 with the sun jvm, before we run into memory management problems.We use the following jvm args now with sun 1.4: -Xms128m -Xmx128m -Xss64k In order to use such high settinmgs you also need to adjust your web server because by default they don't permit such high levels of concurrency either - I assume as a precaution against DOS attacks.So you have to adjust your Apache or IIS settings. If I recall my experiments properly, the jvm on windows is limited to 2048 threads, so to get beyond that on a single machine you need to have multiple vm's.So, I put several JRun servers under IIS, but then I started to run up against some upper limits of IIS.I never got further than 4000 concurrent connections for a single win2k box with 1 cpu, and that was with three JRun servers under IIS. Hope that helps, BenG. [EMAIL PROTECTED] wrote: Ben, How is the stability and performance of JRun server after you set activeHandlerThreads to 2000? Usually the number of the maxHandlerThreads should be bigger than activeHandlerThreads? As I understand, JRun would not perform well if the number of activeHandlerThreads is too big. Could you share your experience here? How busy would the traffic be on your site and is your site running in UNIX box? Thanks. Kathy --- Ben Groeneveld [EMAIL PROTECTED] wrote: This is true; to achieve high levels of concurrency we run with attribute name=activeHandlerThreads2000/attribute attribute name=maxHandlerThreads2000/attribute Hope that helps, BenG. [EMAIL PROTECTED] wrote: Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon -Original Message- From: Kathy Vance [mailto:[EMAIL PROTECTED] Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you need. Sometimes you could get the same error mentioned while using jsp forward tag. But I believe that Updater 3 may solve forwarding issue on JRun 4. for your info, Kathy --- Jon Austin [EMAIL PROTECTED] wrote: Thanks to all for their input on this topic, I am getting more resource directed to this in the next day or, so
RE: JRUN Stability- reply 2
Sorry.No, actually, I'd just plain forgotten. This thread was a good reminder to me that we have to revisit this for possible checkin. I know who will be knocking when that happens..Keep in touch. Stephen Dupre Macromedia QA -Original Message- From: Ben Groeneveld [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 2:04 PM To: JRun-Talk Subject: Re: JRUN Stability- reply 2 [EMAIL PROTECTED] wrote: Hi Ben, You have to admit we were in some unexplored territory with that hotfix patch.(it's still being discussed). I don't think this applies to the general server hung issue Jon originally posted which is best handled by some of the debugging techniques mentioned by others (stack trace, etc) without changing the environment (JVMs, etc). Your app is very unique.It actually can have 750 concurrent, ACTIVE/RUNNING threads which doesn't resemble the typical web app of 10-20 possible request threads with maybe 5-10 active at any one time and constantly changing.I'm frankly amazed that you were able to tune it so well with JRun and find all those outer limitations of JVMs, etc that you mention. Well of course that is the beauty of our profession - we are all writing unique apps.I hope you didn't find this email on a negative note.I am most appreciative of your help.It's just the absense of a response that puzzled me.Thanks, BenG. Stephen Dupre Macromedia QA -Original Message- From: Ben Groeneveld [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 1:12 PM To: JRun-Talk Subject: Re: JRUN Stability- reply 2 Kathy, we run primarily on windows.I have done some tests on linux, but not to this extent. Our app uses keepalive connections that remain open, so we need a very high level of concurrency.In production we run at 750 concurrent connections (users) per node.The JRun server doesn't seem to pre-allocate the threads, so they remain upper limits.We also run with a non-sanctioned patch provided by macromedia folks, because regular JRun will get stuck at 1000 activeHandlerThreads.They gave me the patch, but in followup email have been quiet to answer my request for info on when the change would be incorporated into the base code.I was working with someone by the name of Stephen Dupre last August; he was most helpful. Using the patch we have tested just beyond 1800 in our lab with the IBM jvm and 1700 with the sun jvm, before we run into memory management problems.We use the following jvm args now with sun 1.4: -Xms128m -Xmx128m -Xss64k In order to use such high settinmgs you also need to adjust your web server because by default they don't permit such high levels of concurrency either - I assume as a precaution against DOS attacks.So you have to adjust your Apache or IIS settings. If I recall my experiments properly, the jvm on windows is limited to 2048 threads, so to get beyond that on a single machine you need to have multiple vm's.So, I put several JRun servers under IIS, but then I started to run up against some upper limits of IIS.I never got further than 4000 concurrent connections for a single win2k box with 1 cpu, and that was with three JRun servers under IIS. Hope that helps, BenG. [EMAIL PROTECTED] wrote: Ben, How is the stability and performance of JRun server after you set activeHandlerThreads to 2000? Usually the number of the maxHandlerThreads should be bigger than activeHandlerThreads? As I understand, JRun would not perform well if the number of activeHandlerThreads is too big. Could you share your experience here? How busy would the traffic be on your site and is your site running in UNIX box? Thanks. Kathy --- Ben Groeneveld [EMAIL PROTECTED] wrote: This is true; to achieve high levels of concurrency we run with attribute name=activeHandlerThreads2000/attribute attribute name=maxHandlerThreads2000/attribute Hope that helps, BenG. [EMAIL PROTECTED] wrote: Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon -Original Message- From: Kathy Vance [mailto:[EMAIL PROTECTED] Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you
Re: JRUN Stability- reply 2
Ben, How is the stability and performance of JRun server after you set activeHandlerThreads to 2000? Usually the number of the maxHandlerThreads should be bigger than activeHandlerThreads? As I understand, JRun would not perform well if the number of activeHandlerThreads is too big. Could you share your experience here? How busy would the traffic be on your site and is your site running in UNIX box? Thanks. Kathy --- Ben Groeneveld [EMAIL PROTECTED] wrote: This is true; to achieve high levels of concurrency we run with attribute name=activeHandlerThreads2000/attribute attribute name=maxHandlerThreads2000/attribute Hope that helps, BenG. [EMAIL PROTECTED] wrote: Thanks for the advice!.. I have Metrics turned on currently, monitoring every 20 seconds, and I get 0/0, 0 Sessions.. It does specifically say Web-Threads so, I looked for an additional setting for the proxy, (as we're using the JRUN connector via IIS on another server) but that was the only metrics option in the jrun.xml file. ~ Jon -Original Message- From: Kathy Vance [mailto:[EMAIL PROTECTED] Jon, I have the same problem while I did loading testing on JRun 4. We spent $500 for macromedia tech support in order to solve the issue. Please check your jrun.xml. There is a service called ProxyService. You need to increase the value of the attribute named activeHandlerThreads to a number based on how busy your app is. I remember the default value is 15. Also, You can turn on Metrics logging to decide how many threads you need. Sometimes you could get the same error mentioned while using jsp forward tag. But I believe that Updater 3 may solve forwarding issue on JRun 4. for your info, Kathy --- Jon Austin [EMAIL PROTECTED] wrote: Thanks to all for their input on this topic, I am getting more resource directed to this in the next day or, so, and will be running through some of the troubleshooting tips given here. I understand that many of you are running successfully, with many concurrent users, the question now, I have for those people, is what kind of scope is your application? Are we simply talking glorified web-sites with a little processing behind them, or are we talking full hard-code business applications. Our application falls heavily on the latter, and before I base conclusions on other peoples abilities to produce results under this environment, I want to be sure that we're in the same ballpark. One error which a user did capture during a server-halt the other day, was : Too many concurrent requests, jcp.endpoint.main.max.threads exceeded. I found documents on how to resolve this on JRUN3.. but none of the files that are referenced in that document, exist on my JRUN4 implimenation.Does anyone know where I can find the new settings fro JRUN4. Thanks ~ Jon [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]