[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: eXelon performance


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.

-david


> -----Original Message-----
> From: Falko Braeutigam [mailto:falko@softwarebuero.de]
> Sent: Tuesday, April 11, 2000 11:48 AM
> To: ozone-users@ozone-db.org
> 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:falko@softwarebuero.de
> softwarebuero m&b (SMB)                    http://www.softwarebuero.de
>