Oracle, JDK 1.3, Orion Re: Orion Performance Tuning
There are a couple of problems you need to be aware of that affected us in a current project. There is a bug in JDK 1.3.0 that can cause the VM to crash when using threads and the -server option. This caused us many a head scratching sessions. It is fixed in JDK 1.3.1 (check the bug fixes). The second one we encountered is with the use of Oracles OCI drivers (8.1.7 & 8.1.7.1). Oracle would occasionally and randomly hang on a select. This would eventually avalanche to a point where Orion would also hang and you couldn't do anything but shutdown (actually you couldn't even shutdown you would have to kill Orion). Eventually we found a bug report (and it is listed as a known bug in the 9i features/release file) that said the Oracle OCI datapooled connections could hang in a multithreaded application. Great ! There are several problems here as well. Oracle 8.1.7 is only certified to work with JDK 1.2.2 and nothing above. (Oracle 9i is supposed to be certified to 1.3.0) Eventually our only solution was to go with thin drivers with JDK 1.3.0 with the -client option. Our system setup for anyone curious Sun Solaris 2.7 Orion 1.5.2 Oracle 8.1.7 JDK 1.3.0 Andrew Panagos - Original Message - From: "Adam Cassar" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Thursday, July 26, 2001 12:43 AM Subject: Re: Orion Performance Tuning > Enable the undocumented option: > > -Xconcurrentio > > You will find that with a large number of simultaneous connections > you will gain a large performance increase. (The sun site claim up to 40%, > but I have only found a 20-30% depending on the app). > > Read > > http://java.sun.com/docs/hotspot/VMOptions.html > > and > > http://java.sun.com/docs/hotspot/PerformanceFAQ.html > > and > > http://java.sun.com/docs/hotspot/gc/index.html > > for a good overview. > > On Wed, Jul 25, 2001 at 10:51:27AM -0700, Robert S. Sfeir wrote: > > Hello all, > > > > I've gone through and read most of the information posted from this list > > about improving the performance of Orion, and increasing the number of > > threads Orion uses to improve its overall performance under load. > > > > What I've been able to do so far, and it's helped a lot, is: > > 1- Added the -Xms and -Xmx switches to make sure Orion starts and uses more > > memory, they're set at 100MB and 300MB respectively, and Orion uses 175MB > > as soon as I start it up, and doesn't seem to grow past 177MB as the day > > goes one and it gets used. > > > > 2- I added the -server switch in front of the java command so we make sure > > we use the Server version of the HotSpot VM. (Boy does this thing pick up > > speed when using the -server switch!) > > > > Is there anything else that can be done, short of clustering, to further > > increase Orion's performance? > > > > My main objective is to make sure we don't get any more weird hangs and > > long wait times in Orion for no apparent reason. Perhaps increasing the > > number of threads Orion uses? I can't seem to find any definite answer on > > that. > > > > Our servlet seems to be fine, but sometimes when clicking through a test > > web site, one url request seemed to just sit there and hang, as if Orion > > was dead, but I could click and request a different URL and get immediate > > response. So I assumed it was threads in Orion which were not being > > managed properly. > > > > After making reading the posts to the list and making the the 2 changes > > above, the problem seemed to have gone away for the most part, except it > > still happens from time to time in Netscape, IE doesn't seem to have this > > problem. I can quit Netscape and go back in and the problem is gone for a > > while. There is no specific time frame for it to happen. It does happen > > consistently when I click, then stop for about 30-60 seconds, then click > > again or reload, and it just sits there and waits for the world to come to > > an end of something. Very bizarre. > > > > Any ideas you may have would be of great help. > > > > Thanks > > R > > > > > > Robert S. Sfeir > > Director of Software Development > > PERCEPTICON corporation, > > in Joint Venture With JTransit > > San Francisco, CA 94123 > > pw - http://www.percepticon.com/ > > jw - http://jtransit.com > > e- [EMAIL PROTECTED] > > > > > > > > > > -- > > Adam Cassar > Technical Development Manager > ___ > NetRegistry http://www.netregistry.net > D: +61 2 9641 8609 | F: +61 2 9699 6088 > PO Box 270 Broadway NSW 2007 Australia > >
Re: Orion Performance Tuning
inline - Original Message - From: "Robert S. Sfeir" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Wednesday, July 25, 2001 11:09 PM Subject: RE: Orion Performance Tuning > At 12:49 PM 7/25/2001, Duffey, Kevin wrote: > >I am interested in your two fixes. Have you (or anyone) noticed that Orion > >actually requires 175MB of RAM? > > I think it's mainly our Servlet that uses this up. I think it depends on > how many servlets you load. > > > Is there a definite need to use both memory > >switches, or perhaps one over the other? What is the use and/or meaning of > >each switch? > > -Xms = minimum amount of memory the JVM will use > -Xmx = mazimum amount of memory the JVM will use > > > What I find funny is I just installed JDK 1.3.1 and noticed the > >/server, /classic and /hotspot dirs under bin which contain the jvm.dll that > >Windows uses. I was actually going to post an email to this and JSP interest > >list asking what the benefits and differences are between the 3 jvms. > > BIG benefits, just try it. > The hotspot IS included in JDK1.3.1, so the -hotspot switch is not needed. Anyhow, the difference between -client and -server switches is the 80-20 model and a more dynamic OSR ( on stack replacement ). The client option uses a static 80-20 model to determine which methods are to be marked as HOT and therefore subject to OSR. The server option however determines OSR at runtime marking methods over a period of time, doing statistics whatever to truly determine how and why and when to do OSR. The client starts immediately and is used for programs that run from a couple of minutes to a day approx, and the 80-20 approach is applicable and "enough for client needs". The server on the other hand requires at least a few hours uptime to determine which methods are HOT. This information is lost on System.exit(int), so, at every restart it has to do all statistics again. But then, a server jvm should not be restarted. For development I would (and do) use -client so I can stop and start the server more often without wait for statistics. The difference is the internal compiler. They are completely different. The server compiler was written from scratch. And for all I know the compiler is not completely finished, and use the client compiler where it does not know how to handle something. So SUN has only released the "safe" compiler and there should not be a need to use -server on development since behaviour will be the same, only time wont. Johan > > I > >haven't been able to find anything on the sun site that details how they are > >different. Can you fill me in if you know, what makes the server jvm better? > > From what I understand, it uses memory and processors more efficiently, > more driven for background apps rather than a client JVM driven with > foreground apps in mind. > > >Is it better overall for all use (other than client-side SWING apps)? I > >thought the hotspot was the best because of the inline JIT that converts > >code to native..and thus should speed it up greatly. Is the server better > >just for production use, or for anyone running Orion locally for web > >development as well? Ideally, I would think we want our development, qa, > >staging and live servers to all run the same JVM to make sure we all see any > >problems that arise. > > I use it for everything here now. No harm, just benefits, you just gotta > have the RAM. > > R > > > Robert S. Sfeir > Director of Software Development > PERCEPTICON corporation, > in Joint Venture With JTransit > San Francisco, CA 94123 > pw - http://www.percepticon.com/ > jw - http://jtransit.com > e- [EMAIL PROTECTED] >
RE: Orion Performance Tuning
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Robert S. > Sfeir > Sent: Wednesday, July 25, 2001 8:51 PM > To: Orion-Interest > Subject: Orion Performance Tuning > > > Hello all, > > I've gone through and read most of the information posted from this list > about improving the performance of Orion, and increasing the number of > threads Orion uses to improve its overall performance under load. > > What I've been able to do so far, and it's helped a lot, is: > 1- Added the -Xms and -Xmx switches to make sure Orion starts and > uses more > memory, they're set at 100MB and 300MB respectively, and Orion uses 175MB > as soon as I start it up, and doesn't seem to grow past 177MB as the day > goes one and it gets used. > > 2- I added the -server switch in front of the java command so we > make sure > we use the Server version of the HotSpot VM. (Boy does this thing pick up > speed when using the -server switch!) > > Is there anything else that can be done, short of clustering, to further > increase Orion's performance? > > My main objective is to make sure we don't get any more weird hangs and > long wait times in Orion for no apparent reason. Perhaps increasing the > number of threads Orion uses? I can't seem to find any definite > answer on > that. > > Our servlet seems to be fine, but sometimes when clicking through a test > web site, one url request seemed to just sit there and hang, as if Orion > was dead, but I could click and request a different URL and get immediate > response. So I assumed it was threads in Orion which were not being > managed properly. > > After making reading the posts to the list and making the the 2 changes > above, the problem seemed to have gone away for the most part, except it > still happens from time to time in Netscape, IE doesn't seem to have this > problem. I can quit Netscape and go back in and the problem is > gone for a > while. There is no specific time frame for it to happen. It does happen > consistently when I click, then stop for about 30-60 seconds, then click > again or reload, and it just sits there and waits for the world > to come to > an end of something. Very bizarre. Maybe you run the server and the browser on the same computer and usual Netscape is very hungry on processor time, a problem encountered by me very often in a combination of IIS and Netscape; Use Task Manager to see if this is the problem; > > Any ideas you may have would be of great help. > > Thanks > R > > > Robert S. Sfeir > Director of Software Development > PERCEPTICON corporation, > in Joint Venture With JTransit > San Francisco, CA 94123 > pw - http://www.percepticon.com/ > jw - http://jtransit.com > e- [EMAIL PROTECTED] >
RE: Orion Performance Tuning
Question..is the HotSpot 2.0 Server JVM the same thing that comes with the JDK 1.3.1 in the /bin/server folder? If I install the full JDK 1.3.1, and not JRE 1.3.1, do I need the HotSpot 2.0? I know this isn't Orion specific, but since we are on the topic of performance tuning Orion and using the -server option, I thought I'd ask. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Adam Cassar > Sent: Wednesday, July 25, 2001 10:44 PM > To: Orion-Interest > Subject: Re: Orion Performance Tuning > > > Enable the undocumented option: > > -Xconcurrentio > > You will find that with a large number of simultaneous connections > you will gain a large performance increase. (The sun site claim up to 40%, > but I have only found a 20-30% depending on the app). > > Read > > http://java.sun.com/docs/hotspot/VMOptions.html > > and > > http://java.sun.com/docs/hotspot/PerformanceFAQ.html > > and > > http://java.sun.com/docs/hotspot/gc/index.html > > for a good overview. > > On Wed, Jul 25, 2001 at 10:51:27AM -0700, Robert S. Sfeir wrote: > > Hello all, > > > > I've gone through and read most of the information posted from > this list > > about improving the performance of Orion, and increasing the number of > > threads Orion uses to improve its overall performance under load. > > > > What I've been able to do so far, and it's helped a lot, is: > > 1- Added the -Xms and -Xmx switches to make sure Orion starts > and uses more > > memory, they're set at 100MB and 300MB respectively, and Orion > uses 175MB > > as soon as I start it up, and doesn't seem to grow past 177MB > as the day > > goes one and it gets used. > > > > 2- I added the -server switch in front of the java command so > we make sure > > we use the Server version of the HotSpot VM. (Boy does this > thing pick up > > speed when using the -server switch!) > > > > Is there anything else that can be done, short of clustering, > to further > > increase Orion's performance? > > > > My main objective is to make sure we don't get any more weird hangs and > > long wait times in Orion for no apparent reason. Perhaps > increasing the > > number of threads Orion uses? I can't seem to find any > definite answer on > > that. > > > > Our servlet seems to be fine, but sometimes when clicking > through a test > > web site, one url request seemed to just sit there and hang, as > if Orion > > was dead, but I could click and request a different URL and get > immediate > > response. So I assumed it was threads in Orion which were not being > > managed properly. > > > > After making reading the posts to the list and making the the 2 changes > > above, the problem seemed to have gone away for the most part, > except it > > still happens from time to time in Netscape, IE doesn't seem to > have this > > problem. I can quit Netscape and go back in and the problem is > gone for a > > while. There is no specific time frame for it to happen. It > does happen > > consistently when I click, then stop for about 30-60 seconds, > then click > > again or reload, and it just sits there and waits for the world > to come to > > an end of something. Very bizarre. > > > > Any ideas you may have would be of great help. > > > > Thanks > > R > > > > > > Robert S. Sfeir > > Director of Software Development > > PERCEPTICON corporation, > > in Joint Venture With JTransit > > San Francisco, CA 94123 > > pw - http://www.percepticon.com/ > > jw - http://jtransit.com > > e- [EMAIL PROTECTED] > > > > > > > > > > -- > > Adam Cassar > Technical Development Manager > ___ > NetRegistry http://www.netregistry.net > D: +61 2 9641 8609 | F: +61 2 9699 6088 > PO Box 270 Broadway NSW 2007 Australia >
Re: Orion Performance Tuning
Enable the undocumented option: -Xconcurrentio You will find that with a large number of simultaneous connections you will gain a large performance increase. (The sun site claim up to 40%, but I have only found a 20-30% depending on the app). Read http://java.sun.com/docs/hotspot/VMOptions.html and http://java.sun.com/docs/hotspot/PerformanceFAQ.html and http://java.sun.com/docs/hotspot/gc/index.html for a good overview. On Wed, Jul 25, 2001 at 10:51:27AM -0700, Robert S. Sfeir wrote: > Hello all, > > I've gone through and read most of the information posted from this list > about improving the performance of Orion, and increasing the number of > threads Orion uses to improve its overall performance under load. > > What I've been able to do so far, and it's helped a lot, is: > 1- Added the -Xms and -Xmx switches to make sure Orion starts and uses more > memory, they're set at 100MB and 300MB respectively, and Orion uses 175MB > as soon as I start it up, and doesn't seem to grow past 177MB as the day > goes one and it gets used. > > 2- I added the -server switch in front of the java command so we make sure > we use the Server version of the HotSpot VM. (Boy does this thing pick up > speed when using the -server switch!) > > Is there anything else that can be done, short of clustering, to further > increase Orion's performance? > > My main objective is to make sure we don't get any more weird hangs and > long wait times in Orion for no apparent reason. Perhaps increasing the > number of threads Orion uses? I can't seem to find any definite answer on > that. > > Our servlet seems to be fine, but sometimes when clicking through a test > web site, one url request seemed to just sit there and hang, as if Orion > was dead, but I could click and request a different URL and get immediate > response. So I assumed it was threads in Orion which were not being > managed properly. > > After making reading the posts to the list and making the the 2 changes > above, the problem seemed to have gone away for the most part, except it > still happens from time to time in Netscape, IE doesn't seem to have this > problem. I can quit Netscape and go back in and the problem is gone for a > while. There is no specific time frame for it to happen. It does happen > consistently when I click, then stop for about 30-60 seconds, then click > again or reload, and it just sits there and waits for the world to come to > an end of something. Very bizarre. > > Any ideas you may have would be of great help. > > Thanks > R > > > Robert S. Sfeir > Director of Software Development > PERCEPTICON corporation, > in Joint Venture With JTransit > San Francisco, CA 94123 > pw - http://www.percepticon.com/ > jw - http://jtransit.com > e- [EMAIL PROTECTED] > > > > -- Adam Cassar Technical Development Manager ___ NetRegistry http://www.netregistry.net D: +61 2 9641 8609 | F: +61 2 9699 6088 PO Box 270 Broadway NSW 2007 Australia
RE: Orion Performance Tuning
Hey there..using JDK 1.3.0 and 1.3.1 (two different boxes). I don't see the -Xmn512M anywhere. I do the java -X to list, and I do see something about incremental GC option...but nothing for -Xmn. Is this a different JVM your using? Or is it JDK 1.4 your using? > -Original Message- > From: Josh P. Motto [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 25, 2001 2:38 PM > To: Orion-Interest > Subject: RE: Orion Performance Tuning > > > Hello, > I also found setting the Min and Max JVM memory > settings (-xmsM and xmxM) greatly > improved performance. > > Here is another JVM trick I used that also helped > - set the NEW GENERATION memory allocation > higher... the switch is -xmnM . This helps > tune the JVM garbage collection and scavenger > frequency to ensure discarded objects are removed > efficiently without unnecessarily halting the > system for a gc priority thread. > > I used -xmn512M and the system flies with no > hang-ups. > > -Josh > --- "Duffey, Kevin" <[EMAIL PROTECTED]> wrote: > > I am interested in your two fixes. Have you (or > > anyone) noticed that Orion > > actually requires 175MB of RAM? Is there a > > definite need to use both memory > > switches, or perhaps one over the other? What > > is the use and/or meaning of > > each switch? What I find funny is I just > > installed JDK 1.3.1 and noticed the > > /server, /classic and /hotspot dirs under bin > > which contain the jvm.dll that > > Windows uses. I was actually going to post an > > email to this and JSP interest > > list asking what the benefits and differences > > are between the 3 jvms. I > > haven't been able to find anything on the sun > > site that details how they are > > different. Can you fill me in if you know, what > > makes the server jvm better? > > Is it better overall for all use (other than > > client-side SWING apps)? I > > thought the hotspot was the best because of the > > inline JIT that converts > > code to native..and thus should speed it up > > greatly. Is the server better > > just for production use, or for anyone running > > Orion locally for web > > development as well? Ideally, I would think we > > want our development, qa, > > staging and live servers to all run the same > > JVM to make sure we all see any > > problems that arise. > > > > Thanks. > > > > > > > -Original Message- > > > From: Robert S. Sfeir > > [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, July 25, 2001 10:51 AM > > > To: Orion-Interest > > > Subject: Orion Performance Tuning > > > > > > > > > Hello all, > > > > > > I've gone through and read most of the > > information posted > > > from this list > > > about improving the performance of Orion, and > > increasing the > > > number of > > > threads Orion uses to improve its overall > > performance under load. > > > > > > What I've been able to do so far, and it's > > helped a lot, is: > > > 1- Added the -Xms and -Xmx switches to make > > sure Orion starts > > > and uses more > > > memory, they're set at 100MB and 300MB > > respectively, and > > > Orion uses 175MB > > > as soon as I start it up, and doesn't seem to > > grow past 177MB > > > as the day > > > goes one and it gets used. > > > > > > 2- I added the -server switch in front of the > > java command so > > > we make sure > > > we use the Server version of the HotSpot VM. > > (Boy does this > > > thing pick up > > > speed when using the -server switch!) > > > > > > Is there anything else that can be done, > > short of clustering, > > > to further > > > increase Orion's performance? > > > > > > My main objective is to make sure we don't > > get any more weird > > > hangs and > > > long wait times in Orion for no apparent > > reason. Perhaps > > > increasing the > > > number of threads Orion uses? I can't seem > > to find any > > > definite answer on > > > that. > > > > > > Our servlet seems to be fine, but sometimes > > when clicking > > > through a test > > > web site, one url request seemed to just sit > > there and hang, > > > as if Orion > > > was dead, but I could click and request a > > different URL and > > &g
RE: Orion Performance Tuning
Does't seem to exit! Here are the X commands for JDK 1.3.1 -Xmixed mixed mode execution (default) -Xint interpreted mode execution only -Xbootclasspath: set search path for bootstrap classes and resources -Xbootclasspath/a: append to end of bootstrap class path -Xbootclasspath/p: prepend in front of bootstrap class path -Xnoclassgc disable class garbage collection -Xincgc enable incremental garbage collection -Xbatch disable background compilation -Xmsset initial Java heap size -Xmxset maximum Java heap size -Xssset java thread stack size -Xprofoutput cpu profiling data -Xrunhprof[:help]|[:=, ...] perform JVMPI heap, cpu, or monitor profiling -Xdebug enable remote debugging -Xfuture enable strictest checks, anticipating future default At 02:38 PM 7/25/2001, you wrote: >Hello, >I also found setting the Min and Max JVM memory >settings (xmsM and xmxM) greatly >improved performance. > >Here is another JVM trick I used that also helped >- set the NEW GENERATION memory allocation >higher... the switch is -xmnM . This helps >tune the JVM garbage collection and scavenger >frequency to ensure discarded objects are removed >efficiently without unnecessarily halting the >system for a gc priority thread. > >I used -xmn512M and the system flies with no >hang-ups. > >-Josh >--- "Duffey, Kevin" <[EMAIL PROTECTED]> wrote: > > I am interested in your two fixes. Have you (or > > anyone) noticed that Orion > > actually requires 175MB of RAM? Is there a > > definite need to use both memory > > switches, or perhaps one over the other? What > > is the use and/or meaning of > > each switch? What I find funny is I just > > installed JDK 1.3.1 and noticed the > > /server, /classic and /hotspot dirs under bin > > which contain the jvm.dll that > > Windows uses. I was actually going to post an > > email to this and JSP interest > > list asking what the benefits and differences > > are between the 3 jvms. I > > haven't been able to find anything on the sun > > site that details how they are > > different. Can you fill me in if you know, what > > makes the server jvm better? > > Is it better overall for all use (other than > > client-side SWING apps)? I > > thought the hotspot was the best because of the > > inline JIT that converts > > code to native..and thus should speed it up > > greatly. Is the server better > > just for production use, or for anyone running > > Orion locally for web > > development as well? Ideally, I would think we > > want our development, qa, > > staging and live servers to all run the same > > JVM to make sure we all see any > > problems that arise. > > > > Thanks. > > > > > > > -Original Message- > > > From: Robert S. Sfeir > > [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, July 25, 2001 10:51 AM > > > To: Orion-Interest > > > Subject: Orion Performance Tuning > > > > > > > > > Hello all, > > > > > > I've gone through and read most of the > > information posted > > > from this list > > > about improving the performance of Orion, and > > increasing the > > > number of > > > threads Orion uses to improve its overall > > performance under load. > > > > > > What I've been able to do so far, and it's > > helped a lot, is: > > > 1- Added the -Xms and -Xmx switches to make > > sure Orion starts > > > and uses more > > > memory, they're set at 100MB and 300MB > > respectively, and > > > Orion uses 175MB > > > as soon as I start it up, and doesn't seem to > > grow past 177MB > > > as the day > > > goes one and it gets used. > > > > > > 2- I added the -server switch in front of the > > java command so > > > we make sure > > > we use the Server version of the HotSpot VM. > > (Boy does this > > > thing pick up > > > speed when using the -server switch!) > > > > > > Is there anything else that can be done, > > short of clustering, > > > to further > > > increase Orion's performance? > > > > > > My main objective is to make sure we don't > > get any more weird > > > hangs and > > > long wait times in Orion for no apparent > > reason. Perhaps > > > increasing the > > > number of threads Orion uses? I can't seem > > to find any > > > definite answer on > > > that. > > > > > > Our servlet seems to be fine, but sometimes > > when clicking > > > through a test > > > web site, one url request seemed to just sit > > there and hang, > > > as if Orion > > > was dead, but I could click and request a > > different URL and > > > get immediate > > > response. So I assumed it was threads in > > Orion which were not being > > > managed properly. > > > > > > After making reading the posts to the list > > and making the the > > > 2 changes > > > above, the problem seemed to have gone away > > for the most > > > part, except it > > > still h
RE: Orion Performance Tuning
Hello, I also found setting the Min and Max JVM memory settings (xmsM and xmxM) greatly improved performance. Here is another JVM trick I used that also helped - set the NEW GENERATION memory allocation higher... the switch is -xmnM . This helps tune the JVM garbage collection and scavenger frequency to ensure discarded objects are removed efficiently without unnecessarily halting the system for a gc priority thread. I used -xmn512M and the system flies with no hang-ups. -Josh --- "Duffey, Kevin" <[EMAIL PROTECTED]> wrote: > I am interested in your two fixes. Have you (or > anyone) noticed that Orion > actually requires 175MB of RAM? Is there a > definite need to use both memory > switches, or perhaps one over the other? What > is the use and/or meaning of > each switch? What I find funny is I just > installed JDK 1.3.1 and noticed the > /server, /classic and /hotspot dirs under bin > which contain the jvm.dll that > Windows uses. I was actually going to post an > email to this and JSP interest > list asking what the benefits and differences > are between the 3 jvms. I > haven't been able to find anything on the sun > site that details how they are > different. Can you fill me in if you know, what > makes the server jvm better? > Is it better overall for all use (other than > client-side SWING apps)? I > thought the hotspot was the best because of the > inline JIT that converts > code to native..and thus should speed it up > greatly. Is the server better > just for production use, or for anyone running > Orion locally for web > development as well? Ideally, I would think we > want our development, qa, > staging and live servers to all run the same > JVM to make sure we all see any > problems that arise. > > Thanks. > > > > -Original Message- > > From: Robert S. Sfeir > [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, July 25, 2001 10:51 AM > > To: Orion-Interest > > Subject: Orion Performance Tuning > > > > > > Hello all, > > > > I've gone through and read most of the > information posted > > from this list > > about improving the performance of Orion, and > increasing the > > number of > > threads Orion uses to improve its overall > performance under load. > > > > What I've been able to do so far, and it's > helped a lot, is: > > 1- Added the -Xms and -Xmx switches to make > sure Orion starts > > and uses more > > memory, they're set at 100MB and 300MB > respectively, and > > Orion uses 175MB > > as soon as I start it up, and doesn't seem to > grow past 177MB > > as the day > > goes one and it gets used. > > > > 2- I added the -server switch in front of the > java command so > > we make sure > > we use the Server version of the HotSpot VM. > (Boy does this > > thing pick up > > speed when using the -server switch!) > > > > Is there anything else that can be done, > short of clustering, > > to further > > increase Orion's performance? > > > > My main objective is to make sure we don't > get any more weird > > hangs and > > long wait times in Orion for no apparent > reason. Perhaps > > increasing the > > number of threads Orion uses? I can't seem > to find any > > definite answer on > > that. > > > > Our servlet seems to be fine, but sometimes > when clicking > > through a test > > web site, one url request seemed to just sit > there and hang, > > as if Orion > > was dead, but I could click and request a > different URL and > > get immediate > > response. So I assumed it was threads in > Orion which were not being > > managed properly. > > > > After making reading the posts to the list > and making the the > > 2 changes > > above, the problem seemed to have gone away > for the most > > part, except it > > still happens from time to time in Netscape, > IE doesn't seem > > to have this > > problem. I can quit Netscape and go back in > and the problem > > is gone for a > > while. There is no specific time frame for > it to happen. It > > does happen > > consistently when I click, then stop for > about 30-60 seconds, > > then click > > again or reload, and it just sits there and > waits for the > > world to come to > > an end of something. Very bizarre. > > > > Any ideas you may have would be of great > help. > > > > Thanks > > R > > > > > > Robert S. Sfeir > > Director of Software Development > > PERCEPTICON corporation, > > in Joint Venture With JTransit > > San Francisco, CA 94123 > > pw - http://www.percepticon.com/ > > jw - http://jtransit.com > > e- [EMAIL PROTECTED] > > > __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
RE: Orion Performance Tuning
At 12:49 PM 7/25/2001, Duffey, Kevin wrote: >I am interested in your two fixes. Have you (or anyone) noticed that Orion >actually requires 175MB of RAM? I think it's mainly our Servlet that uses this up. I think it depends on how many servlets you load. > Is there a definite need to use both memory >switches, or perhaps one over the other? What is the use and/or meaning of >each switch? -Xms = minimum amount of memory the JVM will use -Xmx = mazimum amount of memory the JVM will use > What I find funny is I just installed JDK 1.3.1 and noticed the >/server, /classic and /hotspot dirs under bin which contain the jvm.dll that >Windows uses. I was actually going to post an email to this and JSP interest >list asking what the benefits and differences are between the 3 jvms. BIG benefits, just try it. > I >haven't been able to find anything on the sun site that details how they are >different. Can you fill me in if you know, what makes the server jvm better? From what I understand, it uses memory and processors more efficiently, more driven for background apps rather than a client JVM driven with foreground apps in mind. >Is it better overall for all use (other than client-side SWING apps)? I >thought the hotspot was the best because of the inline JIT that converts >code to native..and thus should speed it up greatly. Is the server better >just for production use, or for anyone running Orion locally for web >development as well? Ideally, I would think we want our development, qa, >staging and live servers to all run the same JVM to make sure we all see any >problems that arise. I use it for everything here now. No harm, just benefits, you just gotta have the RAM. R Robert S. Sfeir Director of Software Development PERCEPTICON corporation, in Joint Venture With JTransit San Francisco, CA 94123 pw - http://www.percepticon.com/ jw - http://jtransit.com e- [EMAIL PROTECTED]
RE: Orion Performance Tuning
I am interested in your two fixes. Have you (or anyone) noticed that Orion actually requires 175MB of RAM? Is there a definite need to use both memory switches, or perhaps one over the other? What is the use and/or meaning of each switch? What I find funny is I just installed JDK 1.3.1 and noticed the /server, /classic and /hotspot dirs under bin which contain the jvm.dll that Windows uses. I was actually going to post an email to this and JSP interest list asking what the benefits and differences are between the 3 jvms. I haven't been able to find anything on the sun site that details how they are different. Can you fill me in if you know, what makes the server jvm better? Is it better overall for all use (other than client-side SWING apps)? I thought the hotspot was the best because of the inline JIT that converts code to native..and thus should speed it up greatly. Is the server better just for production use, or for anyone running Orion locally for web development as well? Ideally, I would think we want our development, qa, staging and live servers to all run the same JVM to make sure we all see any problems that arise. Thanks. > -Original Message- > From: Robert S. Sfeir [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 25, 2001 10:51 AM > To: Orion-Interest > Subject: Orion Performance Tuning > > > Hello all, > > I've gone through and read most of the information posted > from this list > about improving the performance of Orion, and increasing the > number of > threads Orion uses to improve its overall performance under load. > > What I've been able to do so far, and it's helped a lot, is: > 1- Added the -Xms and -Xmx switches to make sure Orion starts > and uses more > memory, they're set at 100MB and 300MB respectively, and > Orion uses 175MB > as soon as I start it up, and doesn't seem to grow past 177MB > as the day > goes one and it gets used. > > 2- I added the -server switch in front of the java command so > we make sure > we use the Server version of the HotSpot VM. (Boy does this > thing pick up > speed when using the -server switch!) > > Is there anything else that can be done, short of clustering, > to further > increase Orion's performance? > > My main objective is to make sure we don't get any more weird > hangs and > long wait times in Orion for no apparent reason. Perhaps > increasing the > number of threads Orion uses? I can't seem to find any > definite answer on > that. > > Our servlet seems to be fine, but sometimes when clicking > through a test > web site, one url request seemed to just sit there and hang, > as if Orion > was dead, but I could click and request a different URL and > get immediate > response. So I assumed it was threads in Orion which were not being > managed properly. > > After making reading the posts to the list and making the the > 2 changes > above, the problem seemed to have gone away for the most > part, except it > still happens from time to time in Netscape, IE doesn't seem > to have this > problem. I can quit Netscape and go back in and the problem > is gone for a > while. There is no specific time frame for it to happen. It > does happen > consistently when I click, then stop for about 30-60 seconds, > then click > again or reload, and it just sits there and waits for the > world to come to > an end of something. Very bizarre. > > Any ideas you may have would be of great help. > > Thanks > R > > > Robert S. Sfeir > Director of Software Development > PERCEPTICON corporation, > in Joint Venture With JTransit > San Francisco, CA 94123 > pw - http://www.percepticon.com/ > jw - http://jtransit.com > e- [EMAIL PROTECTED] >
