Scalability of struts on Orion
Did anyone try to play with struts and see if it scales on Orion? I have built a cluster that runs fine ( 3 machines, one is the loadbalancer and the other 2 form one island) but the pages that use a lot of struts simply do not scale. I am using a testing tool that is able to run multiple virtual users in the same time and many of these VUs simply fail on the logon page. If I have only one Orion server everything works fine. Thank you! Danut _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Scalability
Hello- I am very new to J2EE enterprise server world. I want to construct a website that will capable of serving 30,000 clients at time. What is the maximum number of clientsone Orion production site can support and what is the recommended number of Orion sites needed to support 30,000 clients? Would this involve clustering? All help is appreciated. Thanks. John Flores
Session scalability
Hi I am concerned about the scalability in the way which Orion stores session state and session bean state. It seems that they use some kind of serialization. If they have their own serialization scheme it might be OK. However, if it is standard Java serialization I cannot see that this would be particularly scalable. Hans Barnard [EMAIL PROTECTED]
Re: AW: Update: Performance Scalability
Hi Tom, I would like to know exactly the diference between
ejb-location and pooled-location.
...and other thing...but I thing that Orion team is the only one
who can answer me... How does ORion manage the connection pools???
I mean that Orion only let you set the max-number of connections but I
want to know how many connection does it create at the begining, the
number of connection that it creates when the initial ones are busy, if
these extra connections (out of initials) are destroyed after a certain
time whithout using them, an so on
This is very important because imagine that your application has a
lot of clients and inmediatly you start the server you gonna have 200
hundred clients.. in this situation it cuold be great tha the server
creates at least 250 connections at start. Now imagine that you have a hot
peak of affluence and you run out of connection (250 all busy) you will
need more but because the extension of your application, it would be a
great idea to create extra connections but in groups of 25, and destroy or
not destroy them in a timeout depends on your decision. All this with the
security that they will not be over a certain number of connections that
you set and could cause a fall in your database.
Now imagine the opposite situaion, you have a small application
whith perhaps only two clients connected to the DB at the same time, it
would be a lose of resource if your server creates 100 connections at
start, the best could be to create only 2. And if this connections are
busy it would be awfull to create a extra group of 20 connections at the
same time because probably youwill only need one or two extra connections.
Here you can see how you can take advantage of connection pooling.
I'm sure that Orion manages the connection pools eficently but If
the problem was the connection pools and weblogic let you set all this
values, Have you thought that perhaps your configuration in weblogic is
not the best for your applicaction?
Repect to the Orion team...It would be very interesting to know something
more about how Orion manages connection pooling.
THANKS ALL.
-
David Sierra Fern ndez
E.T.S.I. Telecomunicaci¢n
Universidad de ValladolidAULA CEDETEL
Campus Miguel Delibes E-Mail: [EMAIL PROTECTED]
47011 Valladolid (SPAIN)
--
-- Sierr@ --
On Tue, 4 Jul 2000, Jens Stutte wrote:
Hi Kirk,
i assume he confused (like me some time ago) the different jndi names for
the database connections. In a data-source you specify different locations,
which will be treated differently by the server. The "location" is a 'naked'
standard JDBC connection without pooling or anything. The "ejb-location"
provides server specific wrapper classes for the connections, which provide
such things as pooling, transaction handling for EJBs etc. I don't know the
specific purpose of the "xa-location" and when to use it. Anyway, from
within EJBs you should always use the "ejb-location".
Regards,
Jens Stutte
PS: Example of a data-source:
data-source
name="BaseDB"
class="com.evermind.sql.ConnectionDataSource"
location="jdbc/BaseDB"
xa-location="jdbc/xa/BaseXADB"
ejb-location="jdbc/BaseEJBDB"
inactivity-timeout="60"
url="jdbc:informix-sqli://beatnix.net-media.de:1536/BaseDB:INFORMIXSERVER=on
_beatnix"
connection-driver="com.informix.jdbc.IfxDriver"
username="informix"
password="topsecret"
/
-Ursprüngliche Nachricht-
Von:Kirk Kalvar [mailto:[EMAIL PROTECTED]]
Gesendet am:Dienstag, 4. Juli 2000 17:19
An: Orion-Interest
Betreff:RE: Update: Performance Scalability
Tom:
Could you be more specific? You weren't accessing the db
connection pool, but what did you do to fix it?
Thanks in Advance,
Kirk S. Kalvar
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 04, 2000 9:27 AM
To: Orion-Interest
Subject: Update: Performance Scalability
All,
In a previous message I expressed my concern about
performance as compared with Weblogic 5.1. With
assistance
from Karl Avedal, I made some changes to my application
and
am very pleased to announce that Orion is approximately 2x
faster than Weblogic 5.1.
I wasn't using the DB connection pool
AW: Update: Performance Scalability
In the EJBs of the Pet Store is coded a (or several) JNDI name(s) (don't
know which in this moment). This name must mach to the given name of an
"ejb-location" of orions data-source, not to the given name of "location".
If accidently this _name_ in the pet store is "location", you should set
ejb-location="jdbc/location". If by now the pet store used the "naked
location", you should observe significant performance gains. And - what's
more - only with the ejb-location transactions can be rolled back properly.
Jens
-Ursprüngliche Nachricht-
Von: Kirk Kalvar [mailto:[EMAIL PROTECTED]]
Gesendet am: Dienstag, 4. Juli 2000 23:59
An: Jens Stutte
Betreff: RE: Update: Performance Scalability
Jens:
Thanks, that did clear things up a bit. I think xa-location refers to
X/OPEN DTP transaction resource interface (known as XA).
Sun's Java Pet Store 1.0 (jps) application is using
"location". What would
happen if I changed to ejb-location? Any additional coding?
Performance
gains?
Kirk S. Kalvar
email [EMAIL PROTECTED]
phone 703-591-3361
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jens Stutte
Sent: Tuesday, July 04, 2000 1:26 PM
To: Orion-Interest
Cc: '[EMAIL PROTECTED]'
Subject: AW: Update: Performance Scalability
Hi Kirk,
i assume he confused (like me some time ago) the different
jndi names for
the database connections. In a data-source you specify
different locations,
which will be treated differently by the server. The
"location" is a 'naked'
standard JDBC connection without pooling or anything. The
"ejb-location"
provides server specific wrapper classes for the connections,
which provide
such things as pooling, transaction handling for EJBs etc. I
don't know the
specific purpose of the "xa-location" and when to use it. Anyway, from
within EJBs you should always use the "ejb-location".
Regards,
Jens Stutte
PS: Example of a data-source:
data-source
name="BaseDB"
class="com.evermind.sql.ConnectionDataSource"
location="jdbc/BaseDB"
xa-location="jdbc/xa/BaseXADB"
ejb-location="jdbc/BaseEJBDB"
inactivity-timeout="60"
url="jdbc:informix-sqli://beatnix.net-media.de:1536/BaseDB:INF
ORMIXSERVER=on
_beatnix"
connection-driver="com.informix.jdbc.IfxDriver"
username="informix"
password="topsecret"
/
-Ursprüngliche Nachricht-
Von: Kirk Kalvar [mailto:[EMAIL PROTECTED]]
Gesendet am: Dienstag, 4. Juli 2000 17:19
An: Orion-Interest
Betreff: RE: Update: Performance Scalability
Tom:
Could you be more specific? You weren't accessing the db
connection pool, but what did you do to fix it?
Thanks in Advance,
Kirk S. Kalvar
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 04, 2000 9:27 AM
To: Orion-Interest
Subject: Update: Performance Scalability
All,
In a previous message I expressed my concern about
performance as compared with Weblogic 5.1. With
assistance
from Karl Avedal, I made some changes to my
application
and
am very pleased to announce that Orion is
approximately 2x
faster than Weblogic 5.1.
I wasn't using the DB connection pool and
it is a pleasure
to
work with a product that does conform and
support the
latest
J2EE specification.
In general, migrating from WL to Orion has
been pretty
painless. Most of the changes were
container specific,
config files, etc. and no code changes.
The only code
changes I'm now going to make has to do
with improving my
code. This exercise has identified areas that were
inefficient or were specific to WL.
BTW, my evaluation of Orion and two other
Ejb servers has
resulted in Orion as my choice hands down.
Thanks
Tom
Tom Wnuk
[EMAIL PROTECTED]
[EMAIL PROTECTED]
RE: AW: Update: Performance Scalability
That's a good question but I don't know the answer either. I use ejb-location in my code. I'm going to guess that 'pooled-location' can be used via jsp pages or other Java objects that are not participating in Ejb transactions but maybe someone can confirm that. Unfortunately, the one thing lacking with Orion is documentation. There is someone who is starting a documentation site at: http://www.orionsupport.com/ It still has a long way to go and I'm sure it will get there. I know there's a number of tools that come with Orion but I have never seen any docs on this. As for connections, I would like to see 'startup-connections' and 'soft-max' added to the connection pools. Obviously, 'startup-connections' would be the number at startup and 'soft-max' would be the number of connections always maintained in the pool. Then 'max-connections' would be the absolute maximum that the pool would never exceed. I liked your idea about increasing connections as needed but depending on the database there may be a maximum available from the database server. Tom -Original Message- From: David Sierra Fernandez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 05, 2000 1:28 AM To: [EMAIL PROTECTED] Cc: Orion-Interest Subject: Re: AW: Update: Performance Scalability Hi Tom, I would like to know exactly the diference between ejb-location and pooled-location. ...and other thing...but I thing that Orion team is the only one who can answer me... How does ORion manage the connection pools??? I mean that Orion only let you set the max-number of connections but I want to know how many connection does it create at the begining, the number of connection that it creates when the initial ones are busy, if these extra connections (out of initials) are destroyed after a certain time whithout using them, an so on This is very important because imagine that your application has a lot of clients and inmediatly you start the server you gonna have 200 hundred clients.. in this situation it cuold be great tha the server creates at least 250 connections at start. Now imagine that you have a hot peak of affluence and you run out of connection (250 all busy) you will need more but because the extension of your application, it would be a great idea to create extra connections but in groups of 25, and destroy or not destroy them in a timeout depends on your decision. All this with the security that they will not be over a certain number of connections that you set and could cause a fall in your database. Now imagine the opposite situaion, you have a small application whith perhaps only two clients connected to the DB at the same time, it would be a lose of resource if your server creates 100 connections at start, the best could be to create only 2. And if this connections are busy it would be awfull to create a extra group of 20 connections at the same time because probably youwill only need one or two extra connections. Here you can see how you can take advantage of connection pooling. I'm sure that Orion manages the connection pools eficently but If the problem was the connection pools and weblogic let you set all this values, Have you thought that perhaps your configuration in weblogic is not the best for your applicaction? Repect to the Orion team...It would be very interesting to know something more about how Orion manages connection pooling. THANKS ALL. - David Sierra Fern ndez E.T.S.I. Telecomunicaci¢n Universidad de ValladolidAULA CEDETEL Campus Miguel Delibes E-Mail: [EMAIL PROTECTED] 47011 Valladolid (SPAIN) -- -- Sierr@ -- On Tue, 4 Jul 2000, Jens Stutte wrote: Hi Kirk, i assume he confused (like me some time ago) the different jndi names for the database connections. In a data-source you specify different locations, which will be treated differently by the server. The "location" is a 'naked' standard JDBC connection without pooling or anything. The "ejb-location" provides server specific wrapper classes for the connections, which provide such things as pooling, transaction handling for EJBs etc. I don't know the specific purpose of the "xa-location" and when to use it. Anyway, from within EJBs you should always use the "ejb-location". Regards, Jens Stutte PS: Example of a data-source: data-source name="BaseDB" class="com.evermind.sql.ConnectionDataSource" location="jdbc/BaseDB" xa-location="jdbc/xa/BaseXADB" ejb-location="jdbc/BaseEJBDB" inactivity-timeout="60" url="jdbc:informix-sqli://beatnix.net-media.de:1536/BaseDB:INFORMIXSERVER=on _beatnix" connection-driver="com.informix.jd
[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
Performance Scalability Concern
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).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
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? 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
Update: Performance Scalability
All, In a previous message I expressed my concern about performance as compared with Weblogic 5.1. With assistance from Karl Avedal, I made some changes to my application and am very pleased to announce that Orion is approximately 2x faster than Weblogic 5.1. I wasn't using the DB connection pool and it is a pleasure to work with a product that does conform and support the latest J2EE specification. In general, migrating from WL to Orion has been pretty painless. Most of the changes were container specific, config files, etc. and no code changes. The only code changes I'm now going to make has to do with improving my code. This exercise has identified areas that were inefficient or were specific to WL. BTW, my evaluation of Orion and two other Ejb servers has resulted in Orion as my choice hands down. Thanks Tom Tom Wnuk [EMAIL PROTECTED] [EMAIL PROTECTED] winmail.dat
AW: Update: Performance Scalability
Hi Kirk,
i assume he confused (like me some time ago) the different jndi names for
the database connections. In a data-source you specify different locations,
which will be treated differently by the server. The "location" is a 'naked'
standard JDBC connection without pooling or anything. The "ejb-location"
provides server specific wrapper classes for the connections, which provide
such things as pooling, transaction handling for EJBs etc. I don't know the
specific purpose of the "xa-location" and when to use it. Anyway, from
within EJBs you should always use the "ejb-location".
Regards,
Jens Stutte
PS: Example of a data-source:
data-source
name="BaseDB"
class="com.evermind.sql.ConnectionDataSource"
location="jdbc/BaseDB"
xa-location="jdbc/xa/BaseXADB"
ejb-location="jdbc/BaseEJBDB"
inactivity-timeout="60"
url="jdbc:informix-sqli://beatnix.net-media.de:1536/BaseDB:INFORMIXSERVER=on
_beatnix"
connection-driver="com.informix.jdbc.IfxDriver"
username="informix"
password="topsecret"
/
-Ursprüngliche Nachricht-
Von: Kirk Kalvar [mailto:[EMAIL PROTECTED]]
Gesendet am: Dienstag, 4. Juli 2000 17:19
An: Orion-Interest
Betreff: RE: Update: Performance Scalability
Tom:
Could you be more specific? You weren't accessing the db
connection pool, but what did you do to fix it?
Thanks in Advance,
Kirk S. Kalvar
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 04, 2000 9:27 AM
To: Orion-Interest
Subject: Update: Performance Scalability
All,
In a previous message I expressed my concern about
performance as compared with Weblogic 5.1. With
assistance
from Karl Avedal, I made some changes to my application
and
am very pleased to announce that Orion is approximately 2x
faster than Weblogic 5.1.
I wasn't using the DB connection pool and it is a pleasure
to
work with a product that does conform and support the
latest
J2EE specification.
In general, migrating from WL to Orion has been pretty
painless. Most of the changes were container specific,
config files, etc. and no code changes. The only code
changes I'm now going to make has to do with improving my
code. This exercise has identified areas that were
inefficient or were specific to WL.
BTW, my evaluation of Orion and two other Ejb servers has
resulted in Orion as my choice hands down.
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
