RE: Performance Monitoring Tools
Although it might sound strange I do not believe in low level tools such as OptimzeIt on EJB level - first stage. Usually you end up using a component based framework which might be distributed and EJB overhead just changes results significantly. We switched to a simple set of classes which measure response time on component level and watch it under load. In most cases we are able to locate our hot spots easily. I can not release these classes to public - just think about something which allows you to mark the beginning and the end of a "transaction", measure the time in between - and cumulate. Hope this helps, Jens | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]On Behalf Of Cugier | (extern) | Sent: Tuesday, March 12, 2002 3:25 PM | To: Orion-Interest | Subject: Performance Monitoring Tools | | | Hello, | | we are planning to perform some load tests against our | application (Servlet, | JSP and EJBs). We have found some tools that will create the load on the | server and will monitor the response times. But we haven't found anything | that can be used to monitor Orion's behaviour during the test. | What we want | to monitor is the memory consumption, CPU usage, Sessions etc. | What is important is that we can record what we monitor so we will be able | to look at the resutls of the test later. | | Does anyone has a recommendation for a tool that we can use? | | Thanks | | Peter
Re: Performance Monitoring Tools
Hi Jorge. For generating the load, I have found both Siege and Grinder to be effective. Not fancy, but definately effective. -Steve Jorge Jimenez C wrote: > Hello. I have to do the same tests. > > Can you please tell me about the loading test tools that you've found. > > Thanks in advance. > > JJ > -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208
Re: Performance Monitoring Tools
Optimizeit was quite useful to me. Cpu Usage, Object count, Memory usage, Garbage Collector activity. Also tracked the amount of time spent in each function call. -Steve Cugier (extern) wrote: > Hello, > > we are planning to perform some load tests against our application (Servlet, > JSP and EJBs). We have found some tools that will create the load on the > server and will monitor the response times. But we haven't found anything > that can be used to monitor Orion's behaviour during the test. What we want > to monitor is the memory consumption, CPU usage, Sessions etc. > What is important is that we can record what we monitor so we will be able > to look at the resutls of the test later. > > Does anyone has a recommendation for a tool that we can use? > > Thanks > > Peter > > > -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208
Re: Performance Monitoring Tools
Hello. I have to do the same tests. Can you please tell me about the loading test tools that you've found. Thanks in advance. JJ - Original Message - From: "Cugier (extern)" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Tuesday, March 12, 2002 10:25 AM Subject: Performance Monitoring Tools > Hello, > > we are planning to perform some load tests against our application (Servlet, > JSP and EJBs). We have found some tools that will create the load on the > server and will monitor the response times. But we haven't found anything > that can be used to monitor Orion's behaviour during the test. What we want > to monitor is the memory consumption, CPU usage, Sessions etc. > What is important is that we can record what we monitor so we will be able > to look at the resutls of the test later. > > Does anyone has a recommendation for a tool that we can use? > > Thanks > > Peter > >
Re: Performance declines after moving to a faster Server
NT offers a near infinate number of causes for slowness. Start by installing a good defrag'er and defrag all disks. Your new box may have dog slow disks? Eh? How about size of L2 Cache? Do the PIII's have same size L2 cach as the PII's which I think where all 256Kb... Or maybe there where a bread of early PII's that had 512Kb? Your new box may have a slow as molasis NIC or a crapie driver with your new install of NT. Here's a set of tools to test: - Ftp to both boxes from a 3rd box of a large file (50Mb) time it. This will test both the NIC the LAN and a much lesser extent the disks. - find iozone it's a common tool on unix, I found a copy for NT. It's great a measuring disk io. - Check that your NIC is hard set to full or half duplex. Don't let it choose via "auto". * This might be your problem. * Good luck, curt Cugier (extern) wrote: > Hi, > > we are running a simple web applications - just servlets - on an older > Windows NT Server with two Pentium two 233 MHz CPUs. The performance on the > server was acceptable and pages showed up pretty quickly in the browsers. > > Now we bought a new server (still Windows NT) with two Pentium III Xeon 8xx > MHz CPUs (same amount of memory) and moved the application to the new > server. We expected that the performance would increase because of the > faster CPUs but the opposite happened. Our first tests showed a dramatic > increase of response time. Pages that showed up in just one or two seconds > on the old server, now take ten and more seconds to show up. > > We start Orion with the same java runtime parameters as on the old server. > Also the configuration of the Apache server that we use a front end to Orion > did not change. > > Does anyone have an idea how this performance decline is possible? Shouldn't > it be faster on fastes CPUs? > > -- Curt Smith [EMAIL PROTECTED] (w) 404-463-0973 (h) 404-294-6686
Re: Performance problems (More Info).
SMP = Symmetric Multiprocessing. It's a multi-CPU box. Jeff. On Sat, 07 Apr 2001 14:02:37 +0200 "Marco Pas (GMX)" <[EMAIL PROTECTED]> wrote: >Sorry for my stupid question, but what is a >a SMP machine ? > >Kind Regards, >Marco > >At 18:13 2-4-01 -0700, you wrote: >>Well I found the problem with this and I thought I'd let everyone know for >>the sake of posterity. >> >>I found that this problem did not occur on my non-SMP machines, so I played >>around and found that the HotSpot server behaves wierd with SMP. Switching >>to pure interpretted mode fixes the problem. >> >>It wasn't Orion... >> >>-Original Message- >>From: Aaron Tavistock [mailto:[EMAIL PROTECTED]] >>Sent: Monday, March 26, 2001 12:11 PM >>To: Orion-Interest >>Subject: RE: Performance problems (More Info). >> >> >>JVM Settings -- My normal settings are "-server -Xincgc -Xms128m -Xmx384m". >>I've tried playing around with different JVM options including turning off >>server, using normal gc, running in interpreted mode, running in classic >>mode, et al. I even tried running under JDK1.2.2. While these definately >>effect performance in dramatic ways, none seems to fix this problem. >> >>Garbage Collection -- I tried watching the heap by turning on verbosegc, and >>the pauses do not appear to be timed with a full gc. So thats not it >>either, definately a good thought though... >> >>DB Server -- The DB server itself is performing fine, CPU and memory >>utilization is low. The database is completely accessable via sqlplus or an >>alternative app while these pauses occur. >> >>Connection Pooling vs Orions DataSource Manager -- Interestingly the >>problem seems to go away when I turn off Orions datasources, and run with a >>third party ConnectionPool manager (such as BitMechanic).While this >>fixes my immediate problem it will prevent me from using Orion as an EJB >>container, which is not good. >> >> > -Original Message- >> > From: [EMAIL PROTECTED] >> > [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron >> > Tavistock >> > Sent: Monday, March 26, 2001 1:09 PM >> > To: Orion-Interest >> > Subject: Performance problems... >> > >> > >> > I've been working on getting Orion running in a production >> > environment for a >> > little while now and just when I thought everything was working >> > fine I go to >> > push to production and something load/volume related is creating massive >> > slowdowns. >> > >> > Basically every 250 database accesses or so there is a long pause >> > (20 to 60 >> > second), where nothing occurs. During this pause the CPU load *drops* to >> > practically nothing and our entire site is frozen. I'm not sure exactly >> > where the problem exists; it could be our code, our >> > configuration, or even a >> > bug in Orion. >> > >> > The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure >> > J2EE app, but >> > we're not using EJB. I initially thought it might be a memory issue, but >> > I've played with the JDK heap size and carefully watched memory >> > utilization >> > and thats also not the issue. I even considered that maybe >> > Evermind/IronFlare might have a throttle (to push you to get a >> > license) so I >> > put one of our production licenses on the QA box. >> > >> > I've since gotten a load tester and can reproduce the problem. Oddly, it >> > only happens on pages which require database access. Even more >> > interesting >> > is that it occurs more frequently on pages which utilize more than one >> > connection. But thats about as far as I can narrow it. I've tried the >> > 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles >> > ConnectionCacheImpl and Orions XADataSource implimentation, both show the >> > same behavior (though both are using the Oracle Driver). I've also tried >> > Orions jdbc debug and it shows nothing of interest. >> > >> > So far I've put about a week straight into finding it, and I've just about >> > run out of ideas. I'd really be appreciative if anyone has any good >> > suggestions on where to look. ANyone seen behavior like this before? >> > >> > >
RE: Performance problems (More Info).
Sorry for my stupid question, but what is a a SMP machine ? Kind Regards, Marco At 18:13 2-4-01 -0700, you wrote: >Well I found the problem with this and I thought I'd let everyone know for >the sake of posterity. > >I found that this problem did not occur on my non-SMP machines, so I played >around and found that the HotSpot server behaves wierd with SMP. Switching >to pure interpretted mode fixes the problem. > >It wasn't Orion... > >-Original Message- >From: Aaron Tavistock [mailto:[EMAIL PROTECTED]] >Sent: Monday, March 26, 2001 12:11 PM >To: Orion-Interest >Subject: RE: Performance problems (More Info). > > >JVM Settings -- My normal settings are "-server -Xincgc -Xms128m -Xmx384m". >I've tried playing around with different JVM options including turning off >server, using normal gc, running in interpreted mode, running in classic >mode, et al. I even tried running under JDK1.2.2. While these definately >effect performance in dramatic ways, none seems to fix this problem. > >Garbage Collection -- I tried watching the heap by turning on verbosegc, and >the pauses do not appear to be timed with a full gc. So thats not it >either, definately a good thought though... > >DB Server -- The DB server itself is performing fine, CPU and memory >utilization is low. The database is completely accessable via sqlplus or an >alternative app while these pauses occur. > >Connection Pooling vs Orions DataSource Manager -- Interestingly the >problem seems to go away when I turn off Orions datasources, and run with a >third party ConnectionPool manager (such as BitMechanic).While this >fixes my immediate problem it will prevent me from using Orion as an EJB >container, which is not good. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron > > Tavistock > > Sent: Monday, March 26, 2001 1:09 PM > > To: Orion-Interest > > Subject: Performance problems... > > > > > > I've been working on getting Orion running in a production > > environment for a > > little while now and just when I thought everything was working > > fine I go to > > push to production and something load/volume related is creating massive > > slowdowns. > > > > Basically every 250 database accesses or so there is a long pause > > (20 to 60 > > second), where nothing occurs. During this pause the CPU load *drops* to > > practically nothing and our entire site is frozen. I'm not sure exactly > > where the problem exists; it could be our code, our > > configuration, or even a > > bug in Orion. > > > > The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure > > J2EE app, but > > we're not using EJB. I initially thought it might be a memory issue, but > > I've played with the JDK heap size and carefully watched memory > > utilization > > and thats also not the issue. I even considered that maybe > > Evermind/IronFlare might have a throttle (to push you to get a > > license) so I > > put one of our production licenses on the QA box. > > > > I've since gotten a load tester and can reproduce the problem. Oddly, it > > only happens on pages which require database access. Even more > > interesting > > is that it occurs more frequently on pages which utilize more than one > > connection. But thats about as far as I can narrow it. I've tried the > > 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles > > ConnectionCacheImpl and Orions XADataSource implimentation, both show the > > same behavior (though both are using the Oracle Driver). I've also tried > > Orions jdbc debug and it shows nothing of interest. > > > > So far I've put about a week straight into finding it, and I've just about > > run out of ideas. I'd really be appreciative if anyone has any good > > suggestions on where to look. ANyone seen behavior like this before? > > > >
RE: Performance problems (More Info).
Well I found the problem with this and I thought I'd let everyone know for the sake of posterity. I found that this problem did not occur on my non-SMP machines, so I played around and found that the HotSpot server behaves wierd with SMP. Switching to pure interpretted mode fixes the problem. It wasn't Orion... -Original Message- From: Aaron Tavistock [mailto:[EMAIL PROTECTED]] Sent: Monday, March 26, 2001 12:11 PM To: Orion-Interest Subject: RE: Performance problems (More Info). JVM Settings -- My normal settings are "-server -Xincgc -Xms128m -Xmx384m". I've tried playing around with different JVM options including turning off server, using normal gc, running in interpreted mode, running in classic mode, et al. I even tried running under JDK1.2.2. While these definately effect performance in dramatic ways, none seems to fix this problem. Garbage Collection -- I tried watching the heap by turning on verbosegc, and the pauses do not appear to be timed with a full gc. So thats not it either, definately a good thought though... DB Server -- The DB server itself is performing fine, CPU and memory utilization is low. The database is completely accessable via sqlplus or an alternative app while these pauses occur. Connection Pooling vs Orions DataSource Manager -- Interestingly the problem seems to go away when I turn off Orions datasources, and run with a third party ConnectionPool manager (such as BitMechanic).While this fixes my immediate problem it will prevent me from using Orion as an EJB container, which is not good. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron > Tavistock > Sent: Monday, March 26, 2001 1:09 PM > To: Orion-Interest > Subject: Performance problems... > > > I've been working on getting Orion running in a production > environment for a > little while now and just when I thought everything was working > fine I go to > push to production and something load/volume related is creating massive > slowdowns. > > Basically every 250 database accesses or so there is a long pause > (20 to 60 > second), where nothing occurs. During this pause the CPU load *drops* to > practically nothing and our entire site is frozen. I'm not sure exactly > where the problem exists; it could be our code, our > configuration, or even a > bug in Orion. > > The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure > J2EE app, but > we're not using EJB. I initially thought it might be a memory issue, but > I've played with the JDK heap size and carefully watched memory > utilization > and thats also not the issue. I even considered that maybe > Evermind/IronFlare might have a throttle (to push you to get a > license) so I > put one of our production licenses on the QA box. > > I've since gotten a load tester and can reproduce the problem. Oddly, it > only happens on pages which require database access. Even more > interesting > is that it occurs more frequently on pages which utilize more than one > connection. But thats about as far as I can narrow it. I've tried the > 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles > ConnectionCacheImpl and Orions XADataSource implimentation, both show the > same behavior (though both are using the Oracle Driver). I've also tried > Orions jdbc debug and it shows nothing of interest. > > So far I've put about a week straight into finding it, and I've just about > run out of ideas. I'd really be appreciative if anyone has any good > suggestions on where to look. ANyone seen behavior like this before? > >
RE: Performance problems (More Info).
Aaron Tavistock ([EMAIL PROTECTED]) wrote: > JVM Settings -- My normal settings are "-server -Xincgc -Xms128m -Xmx384m". > I've tried playing around with different JVM options including turning off > server, using normal gc, running in interpreted mode, running in classic > mode, et al. I even tried running under JDK1.2.2. While these definately > effect performance in dramatic ways, none seems to fix this problem. > > Garbage Collection -- I tried watching the heap by turning on verbosegc, and > the pauses do not appear to be timed with a full gc. So thats not it > either, definately a good thought though... > > DB Server -- The DB server itself is performing fine, CPU and memory > utilization is low. The database is completely accessable via sqlplus or an > alternative app while these pauses occur. > > Connection Pooling vs Orions DataSource Manager -- Interestingly the > problem seems to go away when I turn off Orions datasources, and run with a > third party ConnectionPool manager (such as BitMechanic).While this > fixes my immediate problem it will prevent me from using Orion as an EJB > container, which is not good. Have you tried using the com.evermind.sql.ConnectionDataSource? Frankly I have no idea what it is, since it's completely undocumented, but it was recommended to me by Orion support folk a year or so ago. I've been using it ever since. For what it's worth... Gary p.s. Here's my data-sources.xml. We've been using Orion exclusively as a web server so far (in production three months or so?), so the only connection we've used from the set below is 'pooled-location'. > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron > > Tavistock > > Sent: Monday, March 26, 2001 1:09 PM > > To: Orion-Interest > > Subject: Performance problems... > > > > > > I've been working on getting Orion running in a production > > environment for a > > little while now and just when I thought everything was working > > fine I go to > > push to production and something load/volume related is creating massive > > slowdowns. > > > > Basically every 250 database accesses or so there is a long pause > > (20 to 60 > > second), where nothing occurs. During this pause the CPU load *drops* to > > practically nothing and our entire site is frozen. I'm not sure exactly > > where the problem exists; it could be our code, our > > configuration, or even a > > bug in Orion. > > > > The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure > > J2EE app, but > > we're not using EJB. I initially thought it might be a memory issue, but > > I've played with the JDK heap size and carefully watched memory > > utilization > > and thats also not the issue. I even considered that maybe > > Evermind/IronFlare might have a throttle (to push you to get a > > license) so I > > put one of our production licenses on the QA box. > > > > I've since gotten a load tester and can reproduce the problem. Oddly, it > > only happens on pages which require database access. Even more > > interesting > > is that it occurs more frequently on pages which utilize more than one > > connection. But thats about as far as I can narrow it. I've tried the > > 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles > > ConnectionCacheImpl and Orions XADataSource implimentation, both show the > > same behavior (though both are using the Oracle Driver). I've also tried > > Orions jdbc debug and it shows nothing of interest. > > > > So far I've put about a week straight into finding it, and I've just about > > run out of ideas. I'd really be appreciative if anyone has any good > > suggestions on where to look. ANyone seen behavior like this before? > > > > > > >
RE: Performance problems (More Info).
JVM Settings -- My normal settings are "-server -Xincgc -Xms128m -Xmx384m". I've tried playing around with different JVM options including turning off server, using normal gc, running in interpreted mode, running in classic mode, et al. I even tried running under JDK1.2.2. While these definately effect performance in dramatic ways, none seems to fix this problem. Garbage Collection -- I tried watching the heap by turning on verbosegc, and the pauses do not appear to be timed with a full gc. So thats not it either, definately a good thought though... DB Server -- The DB server itself is performing fine, CPU and memory utilization is low. The database is completely accessable via sqlplus or an alternative app while these pauses occur. Connection Pooling vs Orions DataSource Manager -- Interestingly the problem seems to go away when I turn off Orions datasources, and run with a third party ConnectionPool manager (such as BitMechanic).While this fixes my immediate problem it will prevent me from using Orion as an EJB container, which is not good. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron > Tavistock > Sent: Monday, March 26, 2001 1:09 PM > To: Orion-Interest > Subject: Performance problems... > > > I've been working on getting Orion running in a production > environment for a > little while now and just when I thought everything was working > fine I go to > push to production and something load/volume related is creating massive > slowdowns. > > Basically every 250 database accesses or so there is a long pause > (20 to 60 > second), where nothing occurs. During this pause the CPU load *drops* to > practically nothing and our entire site is frozen. I'm not sure exactly > where the problem exists; it could be our code, our > configuration, or even a > bug in Orion. > > The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure > J2EE app, but > we're not using EJB. I initially thought it might be a memory issue, but > I've played with the JDK heap size and carefully watched memory > utilization > and thats also not the issue. I even considered that maybe > Evermind/IronFlare might have a throttle (to push you to get a > license) so I > put one of our production licenses on the QA box. > > I've since gotten a load tester and can reproduce the problem. Oddly, it > only happens on pages which require database access. Even more > interesting > is that it occurs more frequently on pages which utilize more than one > connection. But thats about as far as I can narrow it. I've tried the > 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles > ConnectionCacheImpl and Orions XADataSource implimentation, both show the > same behavior (though both are using the Oracle Driver). I've also tried > Orions jdbc debug and it shows nothing of interest. > > So far I've put about a week straight into finding it, and I've just about > run out of ideas. I'd really be appreciative if anyone has any good > suggestions on where to look. ANyone seen behavior like this before? > >
Re: Performance problems...
A better solution is to figure out why you have so many objects. GC cycles increase linearly with the the more memory you allocate. If you allocate 2GB of memory, then it's normal to hav 10-20 second GC cycles. If you're getting values that are that high (with hotspot) then you need to profile your code and optimise. On Mon, 26 Mar 2001, Salvatore Sferrazza wrote: > I've had similar symptoms with ATG Dynamo. It usually occurs when the VM > decides to garbage collect. The way we get around this is to have > multiple Dynamo instances each with it's own dedicated VM and CPU. This > makes the user experience more acceptable across all sessions on the > system since the garbage collection per user is less noticeable. are you > only using 1 VM right now? > > just a thought. > > Sal > > >
Re: Performance problems...
I've had similar symptoms with ATG Dynamo. It usually occurs when the VM decides to garbage collect. The way we get around this is to have multiple Dynamo instances each with it's own dedicated VM and CPU. This makes the user experience more acceptable across all sessions on the system since the garbage collection per user is less noticeable. are you only using 1 VM right now? just a thought. Sal
RE: Performance problems...
And from totally out in left field, how about conflicting database transaction/table locks. I doubt it, because those tend to be indefinite, but it's a thought anyway! I suspect that the running-out-of- connections idea is more likely to be correct, though... Gary > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron > Tavistock > Sent: Sunday, March 25, 2001 7:09 PM > To: Orion-Interest > Subject: Performance problems... > > > I've been working on getting Orion running in a production environment for a > little while now and just when I thought everything was working fine I go to > push to production and something load/volume related is creating massive > slowdowns. > > Basically every 250 database accesses or so there is a long pause (20 to 60 > second), where nothing occurs. During this pause the CPU load *drops* to > practically nothing and our entire site is frozen. I'm not sure exactly > where the problem exists; it could be our code, our configuration, or even a > bug in Orion. > > The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure J2EE app, but > we're not using EJB. I initially thought it might be a memory issue, but > I've played with the JDK heap size and carefully watched memory utilization > and thats also not the issue. I even considered that maybe > Evermind/IronFlare might have a throttle (to push you to get a license) so I > put one of our production licenses on the QA box. > > I've since gotten a load tester and can reproduce the problem. Oddly, it > only happens on pages which require database access. Even more interesting > is that it occurs more frequently on pages which utilize more than one > connection. But thats about as far as I can narrow it. I've tried the > 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles > ConnectionCacheImpl and Orions XADataSource implimentation, both show the > same behavior (though both are using the Oracle Driver). I've also tried > Orions jdbc debug and it shows nothing of interest. > > So far I've put about a week straight into finding it, and I've just about > run out of ideas. I'd really be appreciative if anyone has any good > suggestions on where to look. ANyone seen behavior like this before? > > >
RE: Performance problems...
What is the maximum number of connections that you have configured your database pool to? Could you be running out of connections? Are you properly releasing the connections back to the pool, and closing results set which might not be needed? During the time that the site is "frozen" (as you indicate 20 to 60 seconds) can you hit a page that is not database related (a simple .JSP perhaps)? Does that return fast (this would determine if your problem is database or Orion related). Have you tried to examine what's happening on the database server side when this occurs? Just some thoughts. -AP_ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Tavistock Sent: Sunday, March 25, 2001 7:09 PM To: Orion-Interest Subject: Performance problems... I've been working on getting Orion running in a production environment for a little while now and just when I thought everything was working fine I go to push to production and something load/volume related is creating massive slowdowns. Basically every 250 database accesses or so there is a long pause (20 to 60 second), where nothing occurs. During this pause the CPU load *drops* to practically nothing and our entire site is frozen. I'm not sure exactly where the problem exists; it could be our code, our configuration, or even a bug in Orion. The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure J2EE app, but we're not using EJB. I initially thought it might be a memory issue, but I've played with the JDK heap size and carefully watched memory utilization and thats also not the issue. I even considered that maybe Evermind/IronFlare might have a throttle (to push you to get a license) so I put one of our production licenses on the QA box. I've since gotten a load tester and can reproduce the problem. Oddly, it only happens on pages which require database access. Even more interesting is that it occurs more frequently on pages which utilize more than one connection. But thats about as far as I can narrow it. I've tried the 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles ConnectionCacheImpl and Orions XADataSource implimentation, both show the same behavior (though both are using the Oracle Driver). I've also tried Orions jdbc debug and it shows nothing of interest. So far I've put about a week straight into finding it, and I've just about run out of ideas. I'd really be appreciative if anyone has any good suggestions on where to look. ANyone seen behavior like this before?
RE: Performance problems...
Q: Are you running the JVM with -server? Q: Could it be a garbage collection related problem? If it's happening at odd times when heap usage is up, it might be gc collecting old jdbc objects? -mike > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron > Tavistock > Sent: Monday, March 26, 2001 1:09 PM > To: Orion-Interest > Subject: Performance problems... > > > I've been working on getting Orion running in a production > environment for a > little while now and just when I thought everything was working > fine I go to > push to production and something load/volume related is creating massive > slowdowns. > > Basically every 250 database accesses or so there is a long pause > (20 to 60 > second), where nothing occurs. During this pause the CPU load *drops* to > practically nothing and our entire site is frozen. I'm not sure exactly > where the problem exists; it could be our code, our > configuration, or even a > bug in Orion. > > The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure > J2EE app, but > we're not using EJB. I initially thought it might be a memory issue, but > I've played with the JDK heap size and carefully watched memory > utilization > and thats also not the issue. I even considered that maybe > Evermind/IronFlare might have a throttle (to push you to get a > license) so I > put one of our production licenses on the QA box. > > I've since gotten a load tester and can reproduce the problem. Oddly, it > only happens on pages which require database access. Even more > interesting > is that it occurs more frequently on pages which utilize more than one > connection. But thats about as far as I can narrow it. I've tried the > 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles > ConnectionCacheImpl and Orions XADataSource implimentation, both show the > same behavior (though both are using the Oracle Driver). I've also tried > Orions jdbc debug and it shows nothing of interest. > > So far I've put about a week straight into finding it, and I've just about > run out of ideas. I'd really be appreciative if anyone has any good > suggestions on where to look. ANyone seen behavior like this before? > >
RE: Performance with ORION
There should be one for each active request. -Original Message- From: Ismael Blesa Part [mailto:[EMAIL PROTECTED]] Sent: 12 March 2001 15:58 To: Orion-Interest Subject: Re: Performance with ORION Yes it should create only one instance of each servlet. What I mean is how to specify how many threads the server should create. JRUN has several parameters to configure this, but I have not seen any one on Orion. Mike Cannon-Brookes wrote: > It _should_ only create one instance of each servlet. Multiple threads are > then used to serve different requests. > > -mike > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Ismael Blesa > > Part > > Sent: Monday, March 12, 2001 8:01 PM > > To: Orion-Interest > > Subject: Performance with ORION > > > > > > > > We have been making some tests with an application that uses a main > > entry point, this is used to redirect all the request to the > > correspondant object. We have found that ORION only creates one instance > > of this servlet and we think that this is causing a bottleneck of our > > application. > > Is there a way to configure how many threads to create to serve more > > requests per second? > > > > > > Thanks > > > > PS: Any news about IronFlare? > > > > > >
Re: Performance with ORION
Yes it should create only one instance of each servlet. What I mean is how to specify how many threads the server should create. JRUN has several parameters to configure this, but I have not seen any one on Orion. Mike Cannon-Brookes wrote: > It _should_ only create one instance of each servlet. Multiple threads are > then used to serve different requests. > > -mike > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Ismael Blesa > > Part > > Sent: Monday, March 12, 2001 8:01 PM > > To: Orion-Interest > > Subject: Performance with ORION > > > > > > > > We have been making some tests with an application that uses a main > > entry point, this is used to redirect all the request to the > > correspondant object. We have found that ORION only creates one instance > > of this servlet and we think that this is causing a bottleneck of our > > application. > > Is there a way to configure how many threads to create to serve more > > requests per second? > > > > > > Thanks > > > > PS: Any news about IronFlare? > > > > > >
RE: Performance with ORION
It _should_ only create one instance of each servlet. Multiple threads are then used to serve different requests. -mike > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Ismael Blesa > Part > Sent: Monday, March 12, 2001 8:01 PM > To: Orion-Interest > Subject: Performance with ORION > > > > We have been making some tests with an application that uses a main > entry point, this is used to redirect all the request to the > correspondant object. We have found that ORION only creates one instance > of this servlet and we think that this is causing a bottleneck of our > application. > Is there a way to configure how many threads to create to serve more > requests per second? > > > Thanks > > PS: Any news about IronFlare? > > >
RE: re Performance test...
No entity beans..not even using EJB on this particular test. It will be a few weeks before I get the clustered test posted. Business needs are consistently coming in and we don't have time to do much else. But as soon as I can I will post those results. > -Original Message- > From: Mark [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 26, 2000 5:21 PM > To: Orion-Interest > Subject: re Performance test... > > > Kevin, quick question on your login test. Does your application use > EntityBeans to represent your users (and therefore are you calling > EntityBean.ejbFind() to load from Oracle?). Or are you using another > mechanism to represent users within your application? > > Many thanks for posting this info, it's extremely helpful! > > --Mark > > > > Hi all, > > Well, using a pretty nifty (and very expensive) testing tool, > I was able > to > do some "minor" testing on a login process of our site. Using Orion, > Oracle > 8i database, and e-load test suite, here are some numbers that I got: > > 25 users - 15 connections in the pool > > pages per second - 43 > pages per day - 3.75 million > transactions per second - 14.5 > transactions per day - 1.26 million > > 25 users - 30 connections in the pool > > pages per second- 26.4 > pages per day - 2.28 million > transactions per second - 8.81 > transactions per day - 761333 > > 25 users - 5 connections in the pool > > pages per second - 51.95 > pages per day - 4.48 million > transactions per second - 17.32 > transactions per day- 1.49 million > > The test is simple. It uses the browser built into the e-test suite > software > and "automates" the login process of our site. I ran the test on a > PIII650, > with 512MB RAM. The database is running on a SUN E450 serve with 512MB > RAM. > The test simply sends a post submitted form with the login name and > password > to a controller servlet that then hits the database using a connection > via > the pool, and logs in the user. All logins were valid, I did not test > invalid login names/passwords. > > Just thought I would share these numbers. Next week I will be > setting up > a > two-server farm, using the load-balancer software that Orion > includes in > > their download. Each server will be dual PIII550 with 512MB > RAM and SCSI > III > RAID hd setup (Actually, they are IBM NetFinitiy 4000R > units). The load > balancer will run on a slow PII300 workstation with 128MB RAM (I hope > this > is good enough). They will be failed over and load-balanced, > and I will > test > the performance on those and post the results here. > > The only thing I am not sure of is if different testing software > performs > about the same..or are there dramatically different results. > > If anyone wants me to attempt to test their site, I'll give > it a go from > > here..but its over a T1 connection, where as my test is done > locally on > a > LAN, so I am sure the results are more skewed. > > > > >
re Performance test...
Kevin, quick question on your login test. Does your application use EntityBeans to represent your users (and therefore are you calling EntityBean.ejbFind() to load from Oracle?). Or are you using another mechanism to represent users within your application? Many thanks for posting this info, it's extremely helpful! --Mark Hi all, Well, using a pretty nifty (and very expensive) testing tool, I was able to do some "minor" testing on a login process of our site. Using Orion, Oracle 8i database, and e-load test suite, here are some numbers that I got: 25 users - 15 connections in the pool pages per second - 43 pages per day - 3.75 million transactions per second - 14.5 transactions per day - 1.26 million 25 users - 30 connections in the pool pages per second- 26.4 pages per day - 2.28 million transactions per second - 8.81 transactions per day - 761333 25 users - 5 connections in the pool pages per second - 51.95 pages per day - 4.48 million transactions per second - 17.32 transactions per day- 1.49 million The test is simple. It uses the browser built into the e-test suite software and "automates" the login process of our site. I ran the test on a PIII650, with 512MB RAM. The database is running on a SUN E450 serve with 512MB RAM. The test simply sends a post submitted form with the login name and password to a controller servlet that then hits the database using a connection via the pool, and logs in the user. All logins were valid, I did not test invalid login names/passwords. Just thought I would share these numbers. Next week I will be setting up a two-server farm, using the load-balancer software that Orion includes in their download. Each server will be dual PIII550 with 512MB RAM and SCSI III RAID hd setup (Actually, they are IBM NetFinitiy 4000R units). The load balancer will run on a slow PII300 workstation with 128MB RAM (I hope this is good enough). They will be failed over and load-balanced, and I will test the performance on those and post the results here. The only thing I am not sure of is if different testing software performs about the same..or are there dramatically different results. If anyone wants me to attempt to test their site, I'll give it a go from here..but its over a T1 connection, where as my test is done locally on a LAN, so I am sure the results are more skewed.
RE: Performance test...
Not sure of the URL, but its RSW software. It costs us something like $35K for the software, including 7 licenses, so its definitely not cheap. But its a great web-based testing tool. A lot of people are used to Silk or QA Partner, but this one is extremely easy to use and learn. While it does allow for written script testing, it uses a sort of macro record mode to record every move you make in their internal browser. You can then set up a databank (a text file) that is used against a load-test, so that it simulates virtual users. I know we can simulat up to 100 virutal users with our licenses, which is small potatoes compared to some users of this tool. One of thier clients simulats 10,000 users. The software has "clients" that can be run on many computers over a network so you can run it over night, each computer simulating say 100 users, all hitting the same one site. Anyways..this is sort of off topic..but if you have any questions, feel free to email me. > -Original Message- > From: Santosh Kumar [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 19, 2000 9:19 PM > To: Orion-Interest > Subject: Re: Performance test... > > > That was a simply great thing to do. Where could i get hold > of this tool. > > Santosh > - Original Message - > From: Duffey, Kevin <[EMAIL PROTECTED]> > To: Orion-Interest <[EMAIL PROTECTED]> > Sent: Friday, October 20, 2000 9:11 AM > Subject: Performance test... > > > > Hi all, > > > > Well, using a pretty nifty (and very expensive) testing > tool, I was able > to > > do some "minor" testing on a login process of our site. Using Orion, > Oracle > > 8i database, and e-load test suite, here are some numbers > that I got: > > > > 25 users - 15 connections in the pool > > > > pages per second - 43 > > pages per day - 3.75 million > > transactions per second - 14.5 > > transactions per day - 1.26 million > > > > 25 users - 30 connections in the pool > > > > pages per second- 26.4 > > pages per day - 2.28 million > > transactions per second - 8.81 > > transactions per day - 761333 > > > > 25 users - 5 connections in the pool > > > > pages per second - 51.95 > > pages per day - 4.48 million > > transactions per second - 17.32 > > transactions per day- 1.49 million > > > > The test is simple. It uses the browser built into the e-test suite > software > > and "automates" the login process of our site. I ran the test on a > PIII650, > > with 512MB RAM. The database is running on a SUN E450 serve > with 512MB > RAM. > > The test simply sends a post submitted form with the login name and > password > > to a controller servlet that then hits the database using a > connection via > > the pool, and logs in the user. All logins were valid, I > did not test > > invalid login names/passwords. > > > > Just thought I would share these numbers. Next week I will > be setting up a > > two-server farm, using the load-balancer software that > Orion includes in > > their download. Each server will be dual PIII550 with 512MB > RAM and SCSI > III > > RAID hd setup (Actually, they are IBM NetFinitiy 4000R > units). The load > > balancer will run on a slow PII300 workstation with 128MB > RAM (I hope this > > is good enough). They will be failed over and > load-balanced, and I will > test > > the performance on those and post the results here. > > > > The only thing I am not sure of is if different testing > software performs > > about the same..or are there dramatically different results. > > > > If anyone wants me to attempt to test their site, I'll give > it a go from > > here..but its over a T1 connection, where as my test is > done locally on a > > LAN, so I am sure the results are more skewed. > > > > > > >
Re: Performance test...
That was a simply great thing to do. Where could i get hold of this tool. Santosh - Original Message - From: Duffey, Kevin <[EMAIL PROTECTED]> To: Orion-Interest <[EMAIL PROTECTED]> Sent: Friday, October 20, 2000 9:11 AM Subject: Performance test... > Hi all, > > Well, using a pretty nifty (and very expensive) testing tool, I was able to > do some "minor" testing on a login process of our site. Using Orion, Oracle > 8i database, and e-load test suite, here are some numbers that I got: > > 25 users - 15 connections in the pool > > pages per second - 43 > pages per day - 3.75 million > transactions per second - 14.5 > transactions per day - 1.26 million > > 25 users - 30 connections in the pool > > pages per second- 26.4 > pages per day - 2.28 million > transactions per second - 8.81 > transactions per day - 761333 > > 25 users - 5 connections in the pool > > pages per second - 51.95 > pages per day - 4.48 million > transactions per second - 17.32 > transactions per day- 1.49 million > > The test is simple. It uses the browser built into the e-test suite software > and "automates" the login process of our site. I ran the test on a PIII650, > with 512MB RAM. The database is running on a SUN E450 serve with 512MB RAM. > The test simply sends a post submitted form with the login name and password > to a controller servlet that then hits the database using a connection via > the pool, and logs in the user. All logins were valid, I did not test > invalid login names/passwords. > > Just thought I would share these numbers. Next week I will be setting up a > two-server farm, using the load-balancer software that Orion includes in > their download. Each server will be dual PIII550 with 512MB RAM and SCSI III > RAID hd setup (Actually, they are IBM NetFinitiy 4000R units). The load > balancer will run on a slow PII300 workstation with 128MB RAM (I hope this > is good enough). They will be failed over and load-balanced, and I will test > the performance on those and post the results here. > > The only thing I am not sure of is if different testing software performs > about the same..or are there dramatically different results. > > If anyone wants me to attempt to test their site, I'll give it a go from > here..but its over a T1 connection, where as my test is done locally on a > LAN, so I am sure the results are more skewed. > > >
Re: Performance
On Mon, Oct 09, 2000 at 05:54:13PM -0400, Sarathy Mattaparti wrote: > i bought windows 2000 Server (with 10 Clients ) for $1200.. is this the only > option for me to change the OS ? It's just my opinion. I don't like Micro$oft products, epecialy because the lack of security. You can't compare UNIX security with Windows security! []s Guilherme Ceschiatti > Sarathy > > > > >On Mon, Oct 09, 2000 at 02:00:06PM -0400, Sarathy Mattaparti wrote: > > > Hi, > > >Previously i used Pentium III 550 MHz and 64 MB RAM and i bought a > >new > > > computer its Dual Pentium III 800 MHZ and 256 MB RAM. i havent seen the > > > difference. I am using Windows 2000 Server as my OS. > > > I just changed the configuration of access log.. > > > > > > Any suggestions to improve the performance ?? > > > > > > >I'd sugest you to leave Windows and use any kind of UNIX. > > > >[]s > >Guiga > > > > _ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. > > >
Re: Performance
What we are doing is using JavaBeans to collect data from Entity or Session beans. This seems to work nice in that the java beans are then invoked by the presentation layer and scoped appropriately. This approach has not introduced any performance issues. Just a thought. -Danno - Original Message - From: "Rafael Alvarez" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Tuesday, October 10, 2000 2:07 PM Subject: Re: Performance > Hi, > > This mail is useful only if you're using entity EJBs. > Because EJB is RMI on steroids (is more than that, but let's keep it > simple), if you need more that one entity to get the data you need for > the presentation layer you end up opening a lot of rmi connections, > with the overhead it implies. > The solution is simple, yet elegant: Create a Session Bean, collect > all the data (raw data, not the remotes) from the Entity Beans and use > that for the presentation. That way you use only one rmi connection. > > > Hope this help. > > > -- > Best regards, > Rafaelmailto:[EMAIL PROTECTED] > > > >
Re: Performance
Usually a good answer, but take a look at http://www.volano.com/report.html The arguably most stable Linux JVM, Blackdown, is pretty far down the list At 06:31 PM 10/9/00 -0200, you wrote: >On Mon, Oct 09, 2000 at 02:00:06PM -0400, Sarathy Mattaparti wrote: > > Hi, > >Previously i used Pentium III 550 MHz and 64 MB RAM and i bought a new > > computer its Dual Pentium III 800 MHZ and 256 MB RAM. i havent seen the > > difference. I am using Windows 2000 Server as my OS. > > I just changed the configuration of access log.. > > > > Any suggestions to improve the performance ?? > > > >I'd sugest you to leave Windows and use any kind of UNIX. > >[]s >Guiga
Re: Performance
Hi, This mail is useful only if you're using entity EJBs. Because EJB is RMI on steroids (is more than that, but let's keep it simple), if you need more that one entity to get the data you need for the presentation layer you end up opening a lot of rmi connections, with the overhead it implies. The solution is simple, yet elegant: Create a Session Bean, collect all the data (raw data, not the remotes) from the Entity Beans and use that for the presentation. That way you use only one rmi connection. Hope this help. -- Best regards, Rafaelmailto:[EMAIL PROTECTED]
RE: Performance
First of all, an 800Mhz cpu isn't terribly faster than a single 550. I have gone from 400 to 800 and don't see too much difference, about 12% or so. Second of all, dual cpus don't get utilized to their full potential unless an application is programed to use them properly. 3D rendering software, for example usually makes good use of two cpus for extra horsepower. In the case of Orion, unless the jvm uses both cpus properly, you wont see much of a difference. In what respect are you not seeing performance? Are you doing a 1000 virtual user load test and not seeing much of a difference? > -Original Message- > From: Sarathy Mattaparti [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 09, 2000 11:00 AM > To: Orion-Interest > Subject: Performance > > > Hi, >Previously i used Pentium III 550 MHz and 64 MB RAM and i > bought a new > computer its Dual Pentium III 800 MHZ and 256 MB RAM. i > havent seen the > difference. I am using Windows 2000 Server as my OS. > I just changed the configuration of access log.. > > Any suggestions to improve the performance ?? > > Thanks > Sarathy > > __ > ___ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
Re: Performance
i bought windows 2000 Server (with 10 Clients ) for $1200.. is this the only option for me to change the OS ? Sarathy > >On Mon, Oct 09, 2000 at 02:00:06PM -0400, Sarathy Mattaparti wrote: > > Hi, > >Previously i used Pentium III 550 MHz and 64 MB RAM and i bought a >new > > computer its Dual Pentium III 800 MHZ and 256 MB RAM. i havent seen the > > difference. I am using Windows 2000 Server as my OS. > > I just changed the configuration of access log.. > > > > Any suggestions to improve the performance ?? > > > >I'd sugest you to leave Windows and use any kind of UNIX. > >[]s >Guiga > _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
Re: Performance
On Mon, Oct 09, 2000 at 02:00:06PM -0400, Sarathy Mattaparti wrote: > Hi, >Previously i used Pentium III 550 MHz and 64 MB RAM and i bought a new > computer its Dual Pentium III 800 MHZ and 256 MB RAM. i havent seen the > difference. I am using Windows 2000 Server as my OS. > I just changed the configuration of access log.. > > Any suggestions to improve the performance ?? > I'd sugest you to leave Windows and use any kind of UNIX. []s Guiga
Re: Performance
i'm using JSDK 1.3 i have lot of memory 512 MB so its not the problem with memory. i took care of DB connections. i'm unable to find the problem.. in cocumentation it says 5 times faster than iis i agree with that but my case is different.. I really wanna solve this problem, help me. Thanks Sarathy > Critical question: What VM are you using? Also, where are you seeing >the bottleneck? Concurrent RMI connections, long lived db connections, >memory exhaustion? > >Sarathy Mattaparti wrote: > > > > Hi, > >Previously i used Pentium III 550 MHz and 64 MB RAM and i bought a >new > > computer its Dual Pentium III 800 MHZ and 256 MB RAM. i havent seen the > > difference. I am using Windows 2000 Server as my OS. > > I just changed the configuration of access log.. > > > > Any suggestions to improve the performance ?? > > > > Thanks > > Sarathy > > > > >_ > > Get Your Private, Free E-mail from MSN Hotmail at >http://www.hotmail.com. > > > > Share information about yourself, create your own public profile at > > http://profiles.msn.com. > >-- >Jason Rimmer >[EMAIL PROTECTED] > _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
Re: Performance
Critical question: What VM are you using? Also, where are you seeing the bottleneck? Concurrent RMI connections, long lived db connections, memory exhaustion? Sarathy Mattaparti wrote: > > Hi, >Previously i used Pentium III 550 MHz and 64 MB RAM and i bought a new > computer its Dual Pentium III 800 MHZ and 256 MB RAM. i havent seen the > difference. I am using Windows 2000 Server as my OS. > I just changed the configuration of access log.. > > Any suggestions to improve the performance ?? > > Thanks > Sarathy > > _ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. -- Jason Rimmer [EMAIL PROTECTED]
Re: Performance for static files
Dale Bronk wrote: > > That may be true as I was including the time to server the file all the way > to the point of the "little e" stopped spinning. Have you had the following > problems with framesets... > > In Apache/IIS with JRun 2.3.3 the frameset and each individual jsp/html > files popup quickly. In Orion, one frame will be visible and then do the > wait for 10-15 seconds, then the next frame and wait, then the next. > > It doesn't seem to matter if I use only static html or jsp... The "problem" > exists on both. > > Dale I noticed in changes.txt there is a new option to turn off keep-alives. You might try your test again with keep-alives turned off in Orion. I'd be interested to know the results. -- Joel Shellman Chief Software Architect The virally-driven B2B marketplace for outsourcing projects http://www.ants.com/90589781
Re: Performance for static files
At 08:47 08.09.00 , you wrote: >just did a test and it seemed to make a big difference. In IE advanced >options I had Use HTTP1.1 turned off. I turned it back on and it made a big >difference. As a matter of fact, I don't see the problem anymore as of yet. >(after clearing cache). > >Dale then please post it in bugzilla and have them decide if it's a bug in their http1.1 implementation. I think there's enough information in this thread for them. Robert (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
Re: Performance for static files
just did a test and it seemed to make a big difference. In IE advanced options I had Use HTTP1.1 turned off. I turned it back on and it made a big difference. As a matter of fact, I don't see the problem anymore as of yet. (after clearing cache). Dale - Original Message - From: Christof Baumgaertner <[EMAIL PROTECTED]> To: Orion-Interest <[EMAIL PROTECTED]> Sent: Friday, September 08, 2000 3:00 AM Subject: Re: Performance for static files > Looks to me like if Orionserver tries to do HTTP/1.1 Keep-Alive without setting > the Content-length accordingly. Can anybody confirm? > > Dale Bronk wrote: > > > Right now until I am proved otherwise, I disagree. I posted a message a day > > or so ago and have no reply yet. Now I do believe that it is probably some > > setting I have (although I am using the default settings from Orion), but my > > web pages are not served very fast at all. I am on a PIII 256M using > > Windows Server 2000 and tested the same static pages with Apache and IIS and > > they really popup quickly. With Orion, the pages seem to completely display > > but the browser keeps going for up to 10-15 seconds before it stops. > > > > I am not saying I disagree with the benchmarks, what I am saying is I agree > > with them with the correct set of configurations as I have used the same > > static pages on the same machine with Apache, IIS, and Orion. I did not use > > any benchmarking tools other than my eye but it was very obvious (clearing > > browser cache between each request) that as soon as the pages "appeared" to > > be fully display (very small graphics, if any) using Apache and IIS, the > > browser (both IE and NS) stopped. With Orion, the browsers just kept going > > (not sure doing what) for another 10-15 seconds. > > > > Like I said, I am sure it is some configuration but I wish someone would > > tell me what the setting is. I also tried browsing from several different > > machines to make sure that it was not simply my browser. > > > > Dale > > > > - Original Message - > > From: <[EMAIL PROTECTED]> > > To: Orion-Interest <[EMAIL PROTECTED]> > > Sent: Thursday, September 07, 2000 3:51 AM > > Subject: SV: Performance for static files > > > > > Look at the benchmark page... > > > > > > Against Apache and IIS its got no problems at all beating them into the > > > bushes. The url is enclosed, have fun... > > > > > > Klaus Myrseth > > > > > > -Opprinnelig melding- > > > Fra: Christof Baumgaertner [mailto:[EMAIL PROTECTED]] > > > Sendt: 7. september 2000 08:40 > > > Til: Orion-Interest > > > Emne: Performance for static files > > > > > > > > > We have a webbased client/server application which in addition to its > > > dynamic elements has to serve a huge amount of small files (HTML, GIF, > > > JS). I understand that Orionserver's performance for J2EE based > > > applications is pretty good. How about serving static files from the > > > file system? Can it compete with high performance servers like AOL > > > Server, Stronghold Apache or others in this area? > > > > > > Thanks, > > > Christof > > > > > > > > > >
Re: Performance for static files
Looks to me like if Orionserver tries to do HTTP/1.1 Keep-Alive without setting the Content-length accordingly. Can anybody confirm? Dale Bronk wrote: > Right now until I am proved otherwise, I disagree. I posted a message a day > or so ago and have no reply yet. Now I do believe that it is probably some > setting I have (although I am using the default settings from Orion), but my > web pages are not served very fast at all. I am on a PIII 256M using > Windows Server 2000 and tested the same static pages with Apache and IIS and > they really popup quickly. With Orion, the pages seem to completely display > but the browser keeps going for up to 10-15 seconds before it stops. > > I am not saying I disagree with the benchmarks, what I am saying is I agree > with them with the correct set of configurations as I have used the same > static pages on the same machine with Apache, IIS, and Orion. I did not use > any benchmarking tools other than my eye but it was very obvious (clearing > browser cache between each request) that as soon as the pages "appeared" to > be fully display (very small graphics, if any) using Apache and IIS, the > browser (both IE and NS) stopped. With Orion, the browsers just kept going > (not sure doing what) for another 10-15 seconds. > > Like I said, I am sure it is some configuration but I wish someone would > tell me what the setting is. I also tried browsing from several different > machines to make sure that it was not simply my browser. > > Dale > > - Original Message - > From: <[EMAIL PROTECTED]> > To: Orion-Interest <[EMAIL PROTECTED]> > Sent: Thursday, September 07, 2000 3:51 AM > Subject: SV: Performance for static files > > > Look at the benchmark page... > > > > Against Apache and IIS its got no problems at all beating them into the > > bushes. The url is enclosed, have fun... > > > > Klaus Myrseth > > > > -Opprinnelig melding- > > Fra: Christof Baumgaertner [mailto:[EMAIL PROTECTED]] > > Sendt: 7. september 2000 08:40 > > Til: Orion-Interest > > Emne: Performance for static files > > > > > > We have a webbased client/server application which in addition to its > > dynamic elements has to serve a huge amount of small files (HTML, GIF, > > JS). I understand that Orionserver's performance for J2EE based > > applications is pretty good. How about serving static files from the > > file system? Can it compete with high performance servers like AOL > > Server, Stronghold Apache or others in this area? > > > > Thanks, > > Christof > > > > > > begin:vcard n:Baumgärtner;Christof tel;pager:[EMAIL PROTECTED] tel;cell:+49 171 8169911 tel;fax:+49 89 6797 tel;work:+49 89 6797 2220 x-mozilla-html:TRUE url:www.websentric.com org:WebSentric AG adr:;;Raiffeisenallee 5;Oberhaching;;82041;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Vice President CTO x-mozilla-cpt:;-4208 fn:Christof Baumgärtner end:vcard
RE: Performance for static files
I have experienced similar delays with framesets. On the intranet there was a small delay, but with an outside connection the delay was quite long. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dale Bronk Sent: Thursday, September 07, 2000 7:56 PM To: Orion-Interest Subject: Re: Performance for static files That may be true as I was including the time to server the file all the way to the point of the "little e" stopped spinning. Have you had the following problems with framesets... In Apache/IIS with JRun 2.3.3 the frameset and each individual jsp/html files popup quickly. In Orion, one frame will be visible and then do the wait for 10-15 seconds, then the next frame and wait, then the next. It doesn't seem to matter if I use only static html or jsp... The "problem" exists on both. Dale - Original Message - From: "Kevin Duffey" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Thursday, September 07, 2000 1:57 PM Subject: RE: Performance for static files > Hi, > > Two things. One..your correct about the browser keeps on going. I have the > same "problem" on my site. Its strange, but the little E keeps spinning on > the browser for many seconds after the page is displayed, and I am not sure > why. This might be a bug with Orion..maybe it's not closing a connection or > something? > > On the other hand, I have seen much faster results with html AND jsp pages > with Orion over IIS and Apache. > > > > -Original Message- > > From: Dale Bronk [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 07, 2000 5:15 AM > > To: Orion-Interest > > Subject: Re: Performance for static files > > > > > > Right now until I am proved otherwise, I disagree. I posted > > a message a day > > or so ago and have no reply yet. Now I do believe that it is > > probably some > > setting I have (although I am using the default settings from > > Orion), but my > > web pages are not served very fast at all. I am on a PIII 256M using > > Windows Server 2000 and tested the same static pages with > > Apache and IIS and > > they really popup quickly. With Orion, the pages seem to > > completely display > > but the browser keeps going for up to 10-15 seconds before it stops. > > > > I am not saying I disagree with the benchmarks, what I am > > saying is I agree > > with them with the correct set of configurations as I have > > used the same > > static pages on the same machine with Apache, IIS, and Orion. > > I did not use > > any benchmarking tools other than my eye but it was very > > obvious (clearing > > browser cache between each request) that as soon as the pages > > "appeared" to > > be fully display (very small graphics, if any) using Apache > > and IIS, the > > browser (both IE and NS) stopped. With Orion, the browsers > > just kept going > > (not sure doing what) for another 10-15 seconds. > > > > Like I said, I am sure it is some configuration but I wish > > someone would > > tell me what the setting is. I also tried browsing from > > several different > > machines to make sure that it was not simply my browser. > > > > Dale > > > > - Original Message - > > From: <[EMAIL PROTECTED]> > > To: Orion-Interest <[EMAIL PROTECTED]> > > Sent: Thursday, September 07, 2000 3:51 AM > > Subject: SV: Performance for static files > > > > > > > Look at the benchmark page... > > > > > > Against Apache and IIS its got no problems at all beating > > them into the > > > bushes. The url is enclosed, have fun... > > > > > > Klaus Myrseth > > > > > > -Opprinnelig melding- > > > Fra: Christof Baumgaertner [mailto:[EMAIL PROTECTED]] > > > Sendt: 7. september 2000 08:40 > > > Til: Orion-Interest > > > Emne: Performance for static files > > > > > > > > > We have a webbased client/server application which in > > addition to its > > > dynamic elements has to serve a huge amount of small files > > (HTML, GIF, > > > JS). I understand that Orionserver's performance for J2EE based > > > applications is pretty good. How about serving static files from the > > > file system? Can it compete with high performance servers like AOL > > > Server, Stronghold Apache or others in this area? > > > > > > Thanks, > > > Christof > > > > > > > > > > > > > > >
Re: Performance for static files
The problem is I am seeing the same thing on my JSP's. Especially on pages with framesets. In Apache/IIS with JRun 2.3.3 the frameset and each individual jsp/html files popup quickly. In Orion, one frame will be visible and then do the wait for 10-15 seconds, then the next frame and wait, then the next. - Original Message - From: "Juan Pablo Lorandi" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Thursday, September 07, 2000 12:36 PM Subject: RE: Performance for static files > Perhaps a lil' off track, I'd like to point out that: > > you may configure Apache/IIS, or Orion, to work with each other. If you feel > more comfortable > with Apache serving static HTML, GIF & JPEG files, you can have it working; > also it could be > useful to serve script based pages, say PHP, running in-process with Apache > (instead of running > as CGI with Orion). > > My 2c, > > JP > > -Original Message- > From: Dale Bronk [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 07, 2000 9:15 AM > To: Orion-Interest > Subject: Re: Performance for static files > > > Right now until I am proved otherwise, I disagree. I posted a message a day > or so ago and have no reply yet. Now I do believe that it is probably some > setting I have (although I am using the default settings from Orion), but my > web pages are not served very fast at all. I am on a PIII 256M using > Windows Server 2000 and tested the same static pages with Apache and IIS and > they really popup quickly. With Orion, the pages seem to completely display > but the browser keeps going for up to 10-15 seconds before it stops. > > I am not saying I disagree with the benchmarks, what I am saying is I agree > with them with the correct set of configurations as I have used the same > static pages on the same machine with Apache, IIS, and Orion. I did not use > any benchmarking tools other than my eye but it was very obvious (clearing > browser cache between each request) that as soon as the pages "appeared" to > be fully display (very small graphics, if any) using Apache and IIS, the > browser (both IE and NS) stopped. With Orion, the browsers just kept going > (not sure doing what) for another 10-15 seconds. > > Like I said, I am sure it is some configuration but I wish someone would > tell me what the setting is. I also tried browsing from several different > machines to make sure that it was not simply my browser. > > Dale > > - Original Message - > From: <[EMAIL PROTECTED]> > To: Orion-Interest <[EMAIL PROTECTED]> > Sent: Thursday, September 07, 2000 3:51 AM > Subject: SV: Performance for static files > > > > Look at the benchmark page... > > > > Against Apache and IIS its got no problems at all beating them into the > > bushes. The url is enclosed, have fun... > > > > Klaus Myrseth > > > > -Opprinnelig melding- > > Fra: Christof Baumgaertner [mailto:[EMAIL PROTECTED]] > > Sendt: 7. september 2000 08:40 > > Til: Orion-Interest > > Emne: Performance for static files > > > > > > We have a webbased client/server application which in addition to its > > dynamic elements has to serve a huge amount of small files (HTML, GIF, > > JS). I understand that Orionserver's performance for J2EE based > > applications is pretty good. How about serving static files from the > > file system? Can it compete with high performance servers like AOL > > Server, Stronghold Apache or others in this area? > > > > Thanks, > > Christof > > > > > > > > >
Re: Performance for static files
That may be true as I was including the time to server the file all the way to the point of the "little e" stopped spinning. Have you had the following problems with framesets... In Apache/IIS with JRun 2.3.3 the frameset and each individual jsp/html files popup quickly. In Orion, one frame will be visible and then do the wait for 10-15 seconds, then the next frame and wait, then the next. It doesn't seem to matter if I use only static html or jsp... The "problem" exists on both. Dale - Original Message - From: "Kevin Duffey" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Thursday, September 07, 2000 1:57 PM Subject: RE: Performance for static files > Hi, > > Two things. One..your correct about the browser keeps on going. I have the > same "problem" on my site. Its strange, but the little E keeps spinning on > the browser for many seconds after the page is displayed, and I am not sure > why. This might be a bug with Orion..maybe it's not closing a connection or > something? > > On the other hand, I have seen much faster results with html AND jsp pages > with Orion over IIS and Apache. > > > > -Original Message- > > From: Dale Bronk [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 07, 2000 5:15 AM > > To: Orion-Interest > > Subject: Re: Performance for static files > > > > > > Right now until I am proved otherwise, I disagree. I posted > > a message a day > > or so ago and have no reply yet. Now I do believe that it is > > probably some > > setting I have (although I am using the default settings from > > Orion), but my > > web pages are not served very fast at all. I am on a PIII 256M using > > Windows Server 2000 and tested the same static pages with > > Apache and IIS and > > they really popup quickly. With Orion, the pages seem to > > completely display > > but the browser keeps going for up to 10-15 seconds before it stops. > > > > I am not saying I disagree with the benchmarks, what I am > > saying is I agree > > with them with the correct set of configurations as I have > > used the same > > static pages on the same machine with Apache, IIS, and Orion. > > I did not use > > any benchmarking tools other than my eye but it was very > > obvious (clearing > > browser cache between each request) that as soon as the pages > > "appeared" to > > be fully display (very small graphics, if any) using Apache > > and IIS, the > > browser (both IE and NS) stopped. With Orion, the browsers > > just kept going > > (not sure doing what) for another 10-15 seconds. > > > > Like I said, I am sure it is some configuration but I wish > > someone would > > tell me what the setting is. I also tried browsing from > > several different > > machines to make sure that it was not simply my browser. > > > > Dale > > > > - Original Message - > > From: <[EMAIL PROTECTED]> > > To: Orion-Interest <[EMAIL PROTECTED]> > > Sent: Thursday, September 07, 2000 3:51 AM > > Subject: SV: Performance for static files > > > > > > > Look at the benchmark page... > > > > > > Against Apache and IIS its got no problems at all beating > > them into the > > > bushes. The url is enclosed, have fun... > > > > > > Klaus Myrseth > > > > > > -Opprinnelig melding- > > > Fra: Christof Baumgaertner [mailto:[EMAIL PROTECTED]] > > > Sendt: 7. september 2000 08:40 > > > Til: Orion-Interest > > > Emne: Performance for static files > > > > > > > > > We have a webbased client/server application which in > > addition to its > > > dynamic elements has to serve a huge amount of small files > > (HTML, GIF, > > > JS). I understand that Orionserver's performance for J2EE based > > > applications is pretty good. How about serving static files from the > > > file system? Can it compete with high performance servers like AOL > > > Server, Stronghold Apache or others in this area? > > > > > > Thanks, > > > Christof > > > > > > > > > > > > > > >
RE: Performance for static files
Hi, Two things. One..your correct about the browser keeps on going. I have the same "problem" on my site. Its strange, but the little E keeps spinning on the browser for many seconds after the page is displayed, and I am not sure why. This might be a bug with Orion..maybe it's not closing a connection or something? On the other hand, I have seen much faster results with html AND jsp pages with Orion over IIS and Apache. > -Original Message- > From: Dale Bronk [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 07, 2000 5:15 AM > To: Orion-Interest > Subject: Re: Performance for static files > > > Right now until I am proved otherwise, I disagree. I posted > a message a day > or so ago and have no reply yet. Now I do believe that it is > probably some > setting I have (although I am using the default settings from > Orion), but my > web pages are not served very fast at all. I am on a PIII 256M using > Windows Server 2000 and tested the same static pages with > Apache and IIS and > they really popup quickly. With Orion, the pages seem to > completely display > but the browser keeps going for up to 10-15 seconds before it stops. > > I am not saying I disagree with the benchmarks, what I am > saying is I agree > with them with the correct set of configurations as I have > used the same > static pages on the same machine with Apache, IIS, and Orion. > I did not use > any benchmarking tools other than my eye but it was very > obvious (clearing > browser cache between each request) that as soon as the pages > "appeared" to > be fully display (very small graphics, if any) using Apache > and IIS, the > browser (both IE and NS) stopped. With Orion, the browsers > just kept going > (not sure doing what) for another 10-15 seconds. > > Like I said, I am sure it is some configuration but I wish > someone would > tell me what the setting is. I also tried browsing from > several different > machines to make sure that it was not simply my browser. > > Dale > > - Original Message - > From: <[EMAIL PROTECTED]> > To: Orion-Interest <[EMAIL PROTECTED]> > Sent: Thursday, September 07, 2000 3:51 AM > Subject: SV: Performance for static files > > > > Look at the benchmark page... > > > > Against Apache and IIS its got no problems at all beating > them into the > > bushes. The url is enclosed, have fun... > > > > Klaus Myrseth > > > > -Opprinnelig melding- > > Fra: Christof Baumgaertner [mailto:[EMAIL PROTECTED]] > > Sendt: 7. september 2000 08:40 > > Til: Orion-Interest > > Emne: Performance for static files > > > > > > We have a webbased client/server application which in > addition to its > > dynamic elements has to serve a huge amount of small files > (HTML, GIF, > > JS). I understand that Orionserver's performance for J2EE based > > applications is pretty good. How about serving static files from the > > file system? Can it compete with high performance servers like AOL > > Server, Stronghold Apache or others in this area? > > > > Thanks, > > Christof > > > > > > > >
RE: Performance for static files
Perhaps a lil' off track, I'd like to point out that: you may configure Apache/IIS, or Orion, to work with each other. If you feel more comfortable with Apache serving static HTML, GIF & JPEG files, you can have it working; also it could be useful to serve script based pages, say PHP, running in-process with Apache (instead of running as CGI with Orion). My 2c, JP -Original Message- From: Dale Bronk [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 07, 2000 9:15 AM To: Orion-Interest Subject: Re: Performance for static files Right now until I am proved otherwise, I disagree. I posted a message a day or so ago and have no reply yet. Now I do believe that it is probably some setting I have (although I am using the default settings from Orion), but my web pages are not served very fast at all. I am on a PIII 256M using Windows Server 2000 and tested the same static pages with Apache and IIS and they really popup quickly. With Orion, the pages seem to completely display but the browser keeps going for up to 10-15 seconds before it stops. I am not saying I disagree with the benchmarks, what I am saying is I agree with them with the correct set of configurations as I have used the same static pages on the same machine with Apache, IIS, and Orion. I did not use any benchmarking tools other than my eye but it was very obvious (clearing browser cache between each request) that as soon as the pages "appeared" to be fully display (very small graphics, if any) using Apache and IIS, the browser (both IE and NS) stopped. With Orion, the browsers just kept going (not sure doing what) for another 10-15 seconds. Like I said, I am sure it is some configuration but I wish someone would tell me what the setting is. I also tried browsing from several different machines to make sure that it was not simply my browser. Dale - Original Message - From: <[EMAIL PROTECTED]> To: Orion-Interest <[EMAIL PROTECTED]> Sent: Thursday, September 07, 2000 3:51 AM Subject: SV: Performance for static files > Look at the benchmark page... > > Against Apache and IIS its got no problems at all beating them into the > bushes. The url is enclosed, have fun... > > Klaus Myrseth > > -Opprinnelig melding- > Fra: Christof Baumgaertner [mailto:[EMAIL PROTECTED]] > Sendt: 7. september 2000 08:40 > Til: Orion-Interest > Emne: Performance for static files > > > We have a webbased client/server application which in addition to its > dynamic elements has to serve a huge amount of small files (HTML, GIF, > JS). I understand that Orionserver's performance for J2EE based > applications is pretty good. How about serving static files from the > file system? Can it compete with high performance servers like AOL > Server, Stronghold Apache or others in this area? > > Thanks, > Christof > > >
Re: Performance for static files
Right now until I am proved otherwise, I disagree. I posted a message a day or so ago and have no reply yet. Now I do believe that it is probably some setting I have (although I am using the default settings from Orion), but my web pages are not served very fast at all. I am on a PIII 256M using Windows Server 2000 and tested the same static pages with Apache and IIS and they really popup quickly. With Orion, the pages seem to completely display but the browser keeps going for up to 10-15 seconds before it stops. I am not saying I disagree with the benchmarks, what I am saying is I agree with them with the correct set of configurations as I have used the same static pages on the same machine with Apache, IIS, and Orion. I did not use any benchmarking tools other than my eye but it was very obvious (clearing browser cache between each request) that as soon as the pages "appeared" to be fully display (very small graphics, if any) using Apache and IIS, the browser (both IE and NS) stopped. With Orion, the browsers just kept going (not sure doing what) for another 10-15 seconds. Like I said, I am sure it is some configuration but I wish someone would tell me what the setting is. I also tried browsing from several different machines to make sure that it was not simply my browser. Dale - Original Message - From: <[EMAIL PROTECTED]> To: Orion-Interest <[EMAIL PROTECTED]> Sent: Thursday, September 07, 2000 3:51 AM Subject: SV: Performance for static files > Look at the benchmark page... > > Against Apache and IIS its got no problems at all beating them into the > bushes. The url is enclosed, have fun... > > Klaus Myrseth > > -Opprinnelig melding- > Fra: Christof Baumgaertner [mailto:[EMAIL PROTECTED]] > Sendt: 7. september 2000 08:40 > Til: Orion-Interest > Emne: Performance for static files > > > We have a webbased client/server application which in addition to its > dynamic elements has to serve a huge amount of small files (HTML, GIF, > JS). I understand that Orionserver's performance for J2EE based > applications is pretty good. How about serving static files from the > file system? Can it compete with high performance servers like AOL > Server, Stronghold Apache or others in this area? > > Thanks, > Christof > > >
RE: Performance
It is the HelloWorldServlet with the addition of a few lite mathematical operations and a counter. The testing tool is something I built to monitor http, smtp and gopher servers using a threaded Swing tool. Cory At 02:14 PM 8/21/00 -0700, Kevin Duffey wrote: >Its impressive, but that depends on what your testing it with, and what the >test is doing. Is it just a simple JSP page return with static html in >it..or are you hitting the database such as a login process? > > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of Cory Adams >> Sent: Sunday, August 20, 2000 9:33 PM >> To: Orion-Interest >> Subject: Performance >> >> >> I don't normally send gifs around but this is only 11 kb. >> >> It shows the orionconsole (1.2.0). Check the Hits averages for the last >> minute and hour. >> >> The machine is a Pentium III 650 (notebook), Orion 1.2.0, jdk 1.3 with >> two instances of the test app (each running a separate vm on the box as >> well) hitting a modified HelloWorldServlet that does several small >> calculations. >> >> Does anybody else think that is impressive performance or not? I don't >> have much to compare against. >> >> Thanks, >> >> Cory > >
RE: Performance
Its impressive, but that depends on what your testing it with, and what the test is doing. Is it just a simple JSP page return with static html in it..or are you hitting the database such as a login process? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Cory Adams > Sent: Sunday, August 20, 2000 9:33 PM > To: Orion-Interest > Subject: Performance > > > I don't normally send gifs around but this is only 11 kb. > > It shows the orionconsole (1.2.0). Check the Hits averages for the last > minute and hour. > > The machine is a Pentium III 650 (notebook), Orion 1.2.0, jdk 1.3 with > two instances of the test app (each running a separate vm on the box as > well) hitting a modified HelloWorldServlet that does several small > calculations. > > Does anybody else think that is impressive performance or not? I don't > have much to compare against. > > Thanks, > > Cory
RE: Performance & Scalability Concern
I understand but if you didn't have a J2EE container how would you resolve it? Once in the CLASSPATH all objects within the same JVM are effected by the order; therefore, the idea of self-contained components break down. They're all subject to the JVM including J2EE implementations. Do you really want to start dynamically loading your own specific classes via reflection? I don't. How many vendors do you know even truly have as close to a full J2EE implementation that Orion has? JBoss is going to rely on plug-ins so now your reliant on multiple vendors and release schedules. Weblogic ($$$) is very very close but they fall down in some areas as well, and IBM well. Tom -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Eric RichardsonSent: Wednesday, July 05, 2000 8:13 AMTo: Orion-InterestSubject: Re: Performance & Scalability ConcernI see that, but that sets the policy of which libraries to use at the server level. When you have a large codebase then pieces of it and the applications may use different non-binary compatible versions and this breaks the component model of J2EE. Except for the J2EE version, each app should be self reliant. This is what I think anyway. Eric :-) Tom Wnuk wrote: Actually, there is a simple method to turn it off. >From Magnus Stenman: "Remove parser.jar and jaxp.jar from the Orion directory and then start Orion with a -Dxml.parser=xerces switch. This launches Orion using the xerces parser only. I hope it helps." I agree, they have stepped outside the spec on this one but maybe the spec should be changed. How does a container process the ejb-jar.xml file if it can't load a parser? Hopefully, they don't have to write another one just to conform. It's one of those gray areas I think. At least I don't have to 'hack' the jar files and Orion has provided a switch. Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 05, 2000 7:25 AM To: [EMAIL PROTECTED] Subject: Re: Performance & Scalability Concern Tom Wnuk wrote: > I just migrated some ejb's from a Weblogic 5.1 installation to Orion. The > version I'm using is whatever was available from the web site about a week > ago -- orion.jar dated 6-5-2000, v1.xx. > > Some observations: > > 1. XML not DOM Level 2 > My beans have used XML from the beginning and I'm using xerces & xalan. > Orion uses parser.jar from Sun which is DOM Level 1 compliant and includes > the org.w3.* and org.xml.* packages. This creates a problem when my beans > try and utilize methods that are in DOM Level 2 such as Document.normalize() > and Node.importNode(). My temporary solution was to remove those classes > from the parser.jar file, they're then picked up by xerces.jar which resides > in the classpath. IMHO this is a problem in Orion. As far an application is concerned, they should only be able to see the J2EE classes. Somehow the class loader scheme needs to insulate the application from the server classes. In this case XML is not part of the current J2EE spec and I'm hoping they won't add it. I haven't looked at an future specs on J2EE. Eric :-) > > > 2. Performance significantly slower > It's not rocket science, but I clocked the elapsed time it takes to complete > a round trip from a test client. Using the same code, Orion was at least 2x > slower than WL 5.1 and did not scale well when more clients were added. > WL 5.1 Orion 1.x > One client .4xx .8xx > Multiple (3) .6xx 2.xx > > I could live with 2x slower but when adding more clients it simply gets > worse, much worse. For development purposes no problem, not ready for > production use though. > > Also, the only known difference between the two deployments is, the JDBC > driver. I'm reading/writing to an Oracle 8i database using a JDBC 2.0 Type > 2 driver whereas with Orion I'm using JDBC Type 4 (thin driver from Oracle). > I'm sure this adds to the response time issue but I can't believe it's the > cause of the scalability problem. > > I'm sure there's more tweaking I could do with Orion, but as I'm sure > everyone is aware, documentation is hard to find. > > Also, does anyone have any benchmarks using Type 2 vs. Type 4 drivers? > > P
Re: Performance & Scalability Concern
I see that, but that sets the policy of which libraries to use at the server level. When you have a large codebase then pieces of it and the applications may use different non-binary compatible versions and this breaks the component model of J2EE. Except for the J2EE version, each app should be self reliant. This is what I think anyway. Eric :-) Tom Wnuk wrote: Actually, there is a simple method to turn it off. >From Magnus Stenman: "Remove parser.jar and jaxp.jar from the Orion directory and then start Orion with a -Dxml.parser=xerces switch. This launches Orion using the xerces parser only. I hope it helps." I agree, they have stepped outside the spec on this one but maybe the spec should be changed. How does a container process the ejb-jar.xml file if it can't load a parser? Hopefully, they don't have to write another one just to conform. It's one of those gray areas I think. At least I don't have to 'hack' the jar files and Orion has provided a switch. Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 05, 2000 7:25 AM To: [EMAIL PROTECTED] Subject: Re: Performance & Scalability Concern Tom Wnuk wrote: > I just migrated some ejb's from a Weblogic 5.1 installation to Orion. The > version I'm using is whatever was available from the web site about a week > ago -- orion.jar dated 6-5-2000, v1.xx. > > Some observations: > > 1. XML not DOM Level 2 > My beans have used XML from the beginning and I'm using xerces & xalan. > Orion uses parser.jar from Sun which is DOM Level 1 compliant and includes > the org.w3.* and org.xml.* packages. This creates a problem when my beans > try and utilize methods that are in DOM Level 2 such as Document.normalize() > and Node.importNode(). My temporary solution was to remove those classes > from the parser.jar file, they're then picked up by xerces.jar which resides > in the classpath. IMHO this is a problem in Orion. As far an application is concerned, they should only be able to see the J2EE classes. Somehow the class loader scheme needs to insulate the application from the server classes. In this case XML is not part of the current J2EE spec and I'm hoping they won't add it. I haven't looked at an future specs on J2EE. Eric :-) > > > 2. Performance significantly slower > It's not rocket science, but I clocked the elapsed time it takes to complete > a round trip from a test client. Using the same code, Orion was at least 2x > slower than WL 5.1 and did not scale well when more clients were added. > WL 5.1 Orion 1.x > One client .4xx .8xx > Multiple (3) .6xx 2.xx > > I could live with 2x slower but when adding more clients it simply gets > worse, much worse. For development purposes no problem, not ready for > production use though. > > Also, the only known difference between the two deployments is, the JDBC > driver. I'm reading/writing to an Oracle 8i database using a JDBC 2.0 Type > 2 driver whereas with Orion I'm using JDBC Type 4 (thin driver from Oracle). > I'm sure this adds to the response time issue but I can't believe it's the > cause of the scalability problem. > > I'm sure there's more tweaking I could do with Orion, but as I'm sure > everyone is aware, documentation is hard to find. > > Also, does anyone have any benchmarks using Type 2 vs. Type 4 drivers? > > Please, feedback is welcome. > > I'm evaluating Orion, JBoss, and JRun. I'm leaning towards Orion for many > reasons that I won't go into here but scalability is a 'big' issue. > > Thanks > Tom > > Tom Wnuk > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > Name: winmail.dat > winmail.dat Type: application/ms-tnef > Encoding: base64
[Fwd: Re: Performance & Scalability Concern]
Oops, forgot to post to the list. Sorry Tom. Original Message Subject: Re: Performance & Scalability Concern Date: Wed, 05 Jul 2000 07:24:32 -0700 From: Eric Richardson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> Tom Wnuk wrote: > I just migrated some ejb's from a Weblogic 5.1 installation to Orion. The > version I'm using is whatever was available from the web site about a week > ago -- orion.jar dated 6-5-2000, v1.xx. > > Some observations: > > 1. XML not DOM Level 2 > My beans have used XML from the beginning and I'm using xerces & xalan. > Orion uses parser.jar from Sun which is DOM Level 1 compliant and includes > the org.w3.* and org.xml.* packages. This creates a problem when my beans > try and utilize methods that are in DOM Level 2 such as Document.normalize() > and Node.importNode(). My temporary solution was to remove those classes > from the parser.jar file, they're then picked up by xerces.jar which resides > in the classpath. IMHO this is a problem in Orion. As far an application is concerned, they should only be able to see the J2EE classes. Somehow the class loader scheme needs to insulate the application from the server classes. In this case XML is not part of the current J2EE spec and I'm hoping they won't add it. I haven't looked at an future specs on J2EE. Eric :-) > > > 2. Performance significantly slower > It's not rocket science, but I clocked the elapsed time it takes to complete > a round trip from a test client. Using the same code, Orion was at least 2x > slower than WL 5.1 and did not scale well when more clients were added. > WL 5.1 Orion 1.x > One client .4xx.8xx > Multiple (3).6xx2.xx > > I could live with 2x slower but when adding more clients it simply gets > worse, much worse. For development purposes no problem, not ready for > production use though. > > Also, the only known difference between the two deployments is, the JDBC > driver. I'm reading/writing to an Oracle 8i database using a JDBC 2.0 Type > 2 driver whereas with Orion I'm using JDBC Type 4 (thin driver from Oracle). > I'm sure this adds to the response time issue but I can't believe it's the > cause of the scalability problem. > > I'm sure there's more tweaking I could do with Orion, but as I'm sure > everyone is aware, documentation is hard to find. > > Also, does anyone have any benchmarks using Type 2 vs. Type 4 drivers? > > Please, feedback is welcome. > > I'm evaluating Orion, JBoss, and JRun. I'm leaning towards Orion for many > reasons that I won't go into here but scalability is a 'big' issue. > > Thanks > Tom > > Tom Wnuk > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > Name: winmail.dat >winmail.datType: application/ms-tnef > Encoding: base64
RE: Performance & Scalability Concern
First, a few clarificatons Orion does not default to Sun's parser. By default Orion uses Sun's JAXP Optional package, which by default uses Sun's XML Parser. Orion uses this parser mainly for two things: 1. Accessing all xml config/deployment files 2. Used by the XSLServlet built into Orion. By default, Orion uses JAXP conventions to access it's XML Parser. This functionallity can changed by specifying the -Dxml.parser=xerces in the java invocation. A note on this is that this might not be even necessary if you use the Xerces version available on Apache's CVS, as this version can be built as JAXP compatible and therefore you will not need to change anything and the system will automatically use Xerces as Orion's default parser. As for SAX2, DOM2 and XML/Schema, don't worry, as Orion sets up xerces.jar before any other parser/package in it's CLASSPATH, so when trying to use DOM2, SAX2 and the other guys... always the correct classes will be loaded. The problem you are experiencing could be that you have a parser.jar/jaxp.jar pair in your ext directory (jdk/jre/lib/ext) but I assure you that Orion will always find Xerces.jar first in it's CLASSPATH... So for your use it really does not matter which parser Orion is using, as you can access any of the two interchangably. Also, make sure you are running the latest version of Orion (1.1.8 as I write this), which is available by typing "java -jar autoupdate.jar" from Orion's top-level directory. --- As for performance goes, a suggestion I have is to turn off the "development=true" flag in orion/config/global-web-application.xml and use "jikes" as your compiler. I advise in sending your test code to the Orion Team for them to check against the server, as I have also benchmarked Orion vs. Weblogic 5.1 and have found Orion to be at least 1.5 faster in my tests. Best Wishes, Victor Salaman > -Original Message- > From: Tom Wnuk [mailto:[EMAIL PROTECTED]] > Sent: Sunday, July 02, 2000 8:26 PM > To: Orion-Interest > Subject: Performance & Scalability Concern > > I just migrated some ejb's from a Weblogic 5.1 installation to Orion. > The version I'm using is whatever was available from the web site about a > week ago -- orion.jar dated 6-5-2000, v1.xx. > > Some observations: > > 1. XML not DOM Level 2 > My beans have used XML from the beginning and I'm using xerces & xalan. > Orion uses parser.jar from Sun which is DOM Level 1 compliant and includes > the org.w3.* and org.xml.* packages. This creates a problem when my beans > try and utilize methods that are in DOM Level 2 such as > Document.normalize() and Node.importNode(). My temporary solution was to > remove those classes from the parser.jar file, they're then picked up by > xerces.jar which resides in the classpath. > > 2. Performance significantly slower > It's not rocket science, but I clocked the elapsed time it takes to > complete a round trip from a test client. Using the same code, Orion was > at least 2x slower than WL 5.1 and did not scale well when more clients > were added. > WL 5.1 Orion 1.x > One client .4xx.8xx > Multiple (3).6xx2.xx > > I could live with 2x slower but when adding more clients it simply gets > worse, much worse. For development purposes no problem, not ready for > production use though. > > Also, the only known difference between the two deployments is, the JDBC > driver. I'm reading/writing to an Oracle 8i database using a JDBC 2.0 > Type 2 driver whereas with Orion I'm using JDBC Type 4 (thin driver from > Oracle). I'm sure this adds to the response time issue but I can't > believe it's the cause of the scalability problem. > > I'm sure there's more tweaking I could do with Orion, but as I'm sure > everyone is aware, documentation is hard to find. > > Also, does anyone have any benchmarks using Type 2 vs. Type 4 drivers? > > Please, feedback is welcome. > > I'm evaluating Orion, JBoss, and JRun. I'm leaning towards Orion for many > reasons that I won't go into here but scalability is a 'big' issue. > > > Thanks > Tom > > Tom Wnuk > [EMAIL PROTECTED] > [EMAIL PROTECTED] >
Re: Performance & Scalability Concern
Hello Tom, Tom Wnuk wrote: > I just migrated some ejb's from a Weblogic 5.1 installation to Orion. The > version I'm using is whatever was available from the web site about a week > ago -- orion.jar dated 6-5-2000, v1.xx. > Try the latest one by doing a java -jar autoupdate.jar or get http://www.orionserver.com/orion/orion.jar (XML parser question already answered by Magnus, so I won't repeat) > > 2. Performance significantly slower > It's not rocket science, but I clocked the elapsed time it takes to complete > a round trip from a test client. Using the same code, Orion was at least 2x > slower than WL 5.1 and did not scale well when more clients were added. > WL 5.1 Orion 1.x > One client .4xx.8xx > Multiple (3).6xx2.xx > > I could live with 2x slower but when adding more clients it simply gets > worse, much worse. For development purposes no problem, not ready for > production use though. > This is very interesting and not at all like our own testing. If it is ok with you we would be very interested in trying your code to see what could cause this. We should normally be much faster than Weblogic so we want to see if there's something weird happening. What type of EJBs are you using? Session beans? BMP entities? CMP? There could of course be some bug in Orion that acts as a bottleneck and if that is the case we want to get rid of it. I will make some tests on Orion vs. Weblogic right away to see if there's been some bug inserted in a recent version that would make it slower than before. I'll get back to you with results on our testing. Whether the jdbc drivers are causing this is impossible for me to say without testing. > I'm evaluating Orion, JBoss, and JRun. I'm leaning towards Orion for many > reasons that I won't go into here but scalability is a 'big' issue. Believe me, it's a big issue for us too. We're always aiming to be faster than anything else and our server is very highly optimized. If we could get access to your code we would be very pleased, but we understand that you might not want to give it out. Source would help most, but binaries are a help too. Regards, Karl Avedal
