[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: eXelon performance
I figured it was probably Xalan being the hog.
OK, so it seems obvious that bringing the DOM in mem and searching using
Xalan is not a very good solution. What would be some alternatives. Maybe
using XML data binding to bring in XML files in as Java Objects and then
storing the Objects vs. a DOM... then you could use ozones ODMG dot syntax
queries on the objects. I'm not sure how a solution like with would work
with ozone since every class needs an interface for RMI. Maybe there would
be a way to automate this process as part of the XML data binding? Just an
off the wall idea.
Falko, thanks for taking the time to look into this and sharing you
thoughts. Plus, be honest about how darn slow it is at handling XML... but
you know what. There are hardly any good XML storage solutions out there and
even most of those are also slow because they hacked something together.
> -----Original Message-----
> From: Falko Braeutigam [mailto:firstname.lastname@example.org]
> Sent: Wednesday, April 12, 2000 1:38 AM
> To: email@example.com
> Subject: RE: eXelon performance
> On Tue, 11 Apr 2000, David Duddleston wrote:
> > Falko, thanks for doing the test and reporting the detials on
> the process.
> > 20K method calls is allot. Any idea on the number of objects created? I
> > agree, some sort of alternative method is needed to speed performance. I
> > can't imagine how long it would have taken to do the query
> accoss all 8megs
> > of files.
> Xalan needs approx. 1.8s x 30 = 54s (for all 30 files) to process
> the query on
> in-memory DOM! This is five times slower then eXcelon on the
> database! This is
> without the overhead of ozone......
> > -david
> > > -----Original Message-----
> > > From: Falko Braeutigam [mailto:firstname.lastname@example.org]
> > > Sent: Tuesday, April 11, 2000 11:48 AM
> > > To: email@example.com
> > > Subject: RE: eXelon performance
> > >
> > >
> > > On Mon, 10 Apr 2000, David Duddleston wrote:
> > > > > Thanks for the info, David. I will check this with ozone and post
> > > > > results here.
> > > > > Maybe this is good starting point for a server independent XPath
> > > > > benchmark. Or
> > > > > does such a thing already exist?
> > > >
> > > > I don't think anything like this exists, since it is so new.
> > > There are only
> > > > just a few XML storage solutions that support Xpath. I'll be
> > > very interested
> > > > in your results Falko. I'm going to run the same test with
> > > Xalan in the next
> > > > few days just for the heck of it. Let me know if there are any
> > > other tests
> > > > you would like me to run with eXelon.
> > >
> > > [tests on a 400MHz, 64MB Linux/Intel box jdk1.2rc1]
> > >
> > > ozone uses Xalan. So an ozone XPath query is only as fast as the Xalan
> > > implementation. To process the first of your example queries on
> > > a_and_c.xml
> > > Xalan needs 200000 method calls !!! In memory this takes
> 1.8s. (!) In the
> > > database this takes 11s. If we take into account what ozone needs
> > > to do on each
> > > method call (checking access right, object activation,
> > > transaction isolation,
> > > aquiring locks) the ratio is good. However, the overall
> > > performance compared to
> > > eXcelon is bad.
> > >
> > > These test results reflect the disadvantages of the current ozone/XML
> > > architecture. We are using Xalan, which is not aware that it runs on a
> > > *persistent* DOM and therefore does no optimizations in this
> > > regard. And we are
> > > using a persistent DOM that is a simple port of a non-persistent
> > > DOM, again
> > > without optimizations. --> less development work - low
> > > performance. The first
> > > way I see to increase performance is to rework the DOM implementation
> > > regarding the needs of ozone. Any ideas?
> > >
> > >
> > > Falko
> > > --
> > > ______________________________________________________________________
> > > Falko Braeutigam mailto:firstname.lastname@example.org
> > > softwarebuero m&b (SMB) http://www.softwarebuero.de
> > >
> Falko Braeutigam mailto:email@example.com
> softwarebuero m&b (SMB) http://www.softwarebuero.de