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)    .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]
> 

Reply via email to