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
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
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
Did you try to get a stack trace when this was happening? (technote 18339 on www.macromedia.com http://www.macromedia.com ) What platform are you running on? Are you using the server version (/jrun4) or the standalone (/cfusionmx). What backend are you connecting to? Have you applied any patches (hotfixes, new database drivers, etc). I'd not ready to finger your code until we look at knownissues that might cause CPU spikes (environment-related, patches, etc). Stephen Dupre Macromedia QA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, April 09, 2004 12:19 AM To: JRun-Talk Subject: JRUN Stability I'm having an issue on a CFMX / JRUN server, when we get around 14 simultaneous users, running an average sized lookup, our CPU spikes, our memory dives, and JRUN bites the dust. I've tried this on a single processor, 512mb machine, and it survived the load for approx 10-15 minutes. I switched to another server with 2 CPU's, and 1gb of ram, and it died in 5 minutes..That server did have two CFMX JRUN server instances on it however. Only one was in active use though, the other was running, but with no connections. Both machines were tested multiple times, and the same behavior continued. Does anyone have any tuning suggestions, or alternative's like porting our app to run off JBOSS? TIA, ~ Jon _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: JRUN Stability
The server in questions is windows 2000, SP4. We're using the Server version (/jrun4)and we're connecting to an Oracle backend. We're on JRUN Updater 3, and we've been running this configuration without issue, for about 6 months now. The problem appears to be load-based.. We usually don't have over 5 people on the server, developers are running their own local servers, so the database is already used to the load.. I'll look into the stack trace, but I do have to co-ordinate several very busy people, in order to get the load on the server, so I'm not sure when I'll be able to do that yet. Thanks, ~ Jon -Original Message- From: Stephen Dupre [mailto:[EMAIL PROTECTED] Did you try to get a stack trace when this was happening? (technote 18339 on www.macromedia.com http://www.macromedia.com ) What platform are you running on? Are you using the server version (/jrun4) or the standalone (/cfusionmx). What backend are you connecting to? Have you applied any patches (hotfixes, new database drivers, etc). I'd not ready to finger your code until we look at knownissues that might cause CPU spikes (environment-related, patches, etc). Stephen Dupre Macromedia QA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, April 09, 2004 12:19 AM To: JRun-Talk Subject: JRUN Stability I'm having an issue on a CFMX / JRUN server, when we get around 14 simultaneous users, running an average sized lookup, our CPU spikes, our memory dives, and JRUN bites the dust. I've tried this on a single processor, 512mb machine, and it survived the load for approx 10-15 minutes. I switched to another server with 2 CPU's, and 1gb of ram, and it died in 5 minutes..That server did have two CFMX JRUN server instances on it however. Only one was in active use though, the other was running, but with no connections. Both machines were tested multiple times, and the same behavior continued. Does anyone have any tuning suggestions, or alternative's like porting our app to run off JBOSS? TIA, ~ Jon _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: JRUN Stability
We run JRun4 with CFMX on win2k in a cluster supporting 1000s of concurrent users and it's quite reliable, believe me.Thanks, BenG. [EMAIL PROTECTED] wrote: The server in questions is windows 2000, SP4. We're using the Server version (/jrun4)and we're connecting to an Oracle backend. We're on JRUN Updater 3, and we've been running this configuration without issue, for about 6 months now. The problem appears to be load-based.. We usually don't have over 5 people on the server, developers are running their own local servers, so the database is already used to the load.. I'll look into the stack trace, but I do have to co-ordinate several very busy people, in order to get the load on the server, so I'm not sure when I'll be able to do that yet. Thanks, ~ Jon -Original Message- From: Stephen Dupre [mailto:[EMAIL PROTECTED] Did you try to get a stack trace when this was happening? (technote 18339 on www.macromedia.com http://www.macromedia.com ) What platform are you running on? Are you using the server version (/jrun4) or the standalone (/cfusionmx). What backend are you connecting to? Have you applied any patches (hotfixes, new database drivers, etc). I'd not ready to finger your code until we look at knownissues that might cause CPU spikes (environment-related, patches, etc). Stephen Dupre Macromedia QA -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, April 09, 2004 12:19 AM To: JRun-Talk Subject: JRUN Stability I'm having an issue on a CFMX / JRUN server, when we get around 14 simultaneous users, running an average sized lookup, our CPU spikes, our memory dives, and JRUN bites the dust. I've tried this on a single processor, 512mb machine, and it survived the load for approx 10-15 minutes. I switched to another server with 2 CPU's, and 1gb of ram, and it died in 5 minutes..That server did have two CFMX JRUN server instances on it however. Only one was in active use though, the other was running, but with no connections. Both machines were tested multiple times, and the same behavior continued. Does anyone have any tuning suggestions, or alternative's like porting our app to run off JBOSS? TIA, ~ Jon _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: JRUN Stability
Well it's nice to know that it does work for someone.. While I do believe you, unfortunately we run a similar setup, and it's not even reliable with 15 concurrent users. Hopefully I can get this resolved before the customer gets loose on it. Thanks, ~ Jon -Original Message- From: Ben Groeneveld [mailto:[EMAIL PROTECTED] We run JRun4 with CFMX on win2k in a cluster supporting 1000s of concurrent users and it's quite reliable, believe me.Thanks, BenG. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: JRUN Stability
Have you isolated the CFM(s) that cause the instability? Specifically, if you just hit any CFM page with 15 concurrent users are there problems? In your first email you mentioned something about a lookup. Have you tried the following?: 1) Using a different JVM. 2) Using trusted cache. 3) Done these things: http://www.macromedia.com/support/jrun/ts/documents/4.0_unresponsive.htm 4) Calling Macromedia Tech Support. -Original Message- From: Jon Austin [mailto:[EMAIL PROTECTED] Sent: Friday, April 09, 2004 10:44 AM To: JRun-Talk Subject: RE: JRUN Stability Well it's nice to know that it does work for someone.. While I do believe you, unfortunately we run a similar setup, and it's not even reliable with 15 concurrent users. Hopefully I can get this resolved before the customer gets loose on it. Thanks, ~ Jon -Original Message- From: Ben Groeneveld [mailto:[EMAIL PROTECTED] We run JRun4 with CFMX on win2k in a cluster supporting 1000s of concurrent users and it's quite reliable, believe me.Thanks, BenG. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: JRUN Stability
Hi Jon- I would be willing to bet that your issue is not in the APPLICATION SERVER, but in the code. This is simply not normal behavior for ColdFusion/JRun or it would not be used as widely as it is. First: are you using ColdFusion? or just JRun? Second: What is your Web Server? Third: depending on whether you are using ColdFusion or JRun, you will want to use the appropriate debugging tools to see what is going on. If you are using both, I would debug first one, then the other. Hope this helps. -Drew Falkman -Original Message- From: Jon Austin [mailto:[EMAIL PROTECTED] Sent: Thursday, April 08, 2004 8:19 PM To: JRun-Talk Subject: JRUN Stability I'm having an issue on a CFMX / JRUN server, when we get around 14 simultaneous users, running an average sized lookup, our CPU spikes, our memory dives, and JRUN bites the dust. I've tried this on a single processor, 512mb machine, and it survived the load for approx 10-15 minutes. I switched to another server with 2 CPU's, and 1gb of ram, and it died in 5 minutes..That server did have two CFMX JRUN server instances on it however. Only one was in active use though, the other was running, but with no connections. Both machines were tested multiple times, and the same behavior continued. Does anyone have any tuning suggestions, or alternative's like porting our app to run off JBOSS? TIA, ~ Jon [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
