[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ozone speed
On Wed, 13 Jun 2001, Stan Pinte wrote:
> At 10:50 13/06/2001 +0200, Falko Braeutigam wrote:
> >On Wed, 13 Jun 2001, Stan Pinte wrote:
> > > At 16:26 12/06/2001 +0200, Falko Braeutigam wrote:
> > > >On Tue, 12 Jun 2001, Stan Pinte wrote:
> > > > > hello,
> > > > >
> > > > > I have a small problem:
> > > > >
> > > > > I have a simple client-server program, which is doing 150 writes to the
> > > > > database, and this takes more or less 12 seconds...I guess I have done
> > > > > something wrong.
> > > > >
> > > > > Would someone point me to some good benchmarking code?
> > > >
> > > >See the samples in $OZONE_HOME/samples. You may start with simple and then
> > > >check the OO1 benchmark sample.
> > > >
> > > >You probably did your 150 "writes" (calling update methods I guess)
> > from the
> > > >client code. Thus, each method call results in a roundtrip to the
> > server and a
> > > >complete transaction begin/prepare/commit cycle - which is probably not
> > > >intended and slow. Putting the 150 item loop into a method of a database
> > > >object
> > > >is the solution. It's much faster _and_ encloses the entire work in _one_
> > > >transaction.
> > >
> > >
> > > Well, my Postgresql relational engine handles 150 writes in a lot less
> > than
> > > 12 seconds...
> >
> >Again, your code probably doesn't take into account the ozone architecture as
> >it probably executes something that can be considered 'business logic' on the
> >client side. This produces incorrect transactional behaviour (the action can
> >break everytime in betwenn the 150 'writes') __and__ results in poor
> >performance. (BTW: this is not just true for ozone. EJB requires this too.)
> >
> >Comparing ozone performance against pure postgresql is like comparing appels
> >against oranges. Comparing ozone against postgres _plus_ a full blown O-R
> >mapper inside an app server would make more sense.
> >
> >On a 350MHz Linux machine ozone produces 1000 highly structured
> >OO1 objects (see the OO1 banchmark) in about 2s. Show me the postgres + O-R
> >mapper combination that is able to do this! ;)
>
> OK, I may agree on this, but in my eyes, ozone seems thus like an EJB
> server, with persistence added...
>
> I was used to the commercial OODBMS, which enables you to do a lot of
> inserts, from the client cache, without paying that price...
Do your inserts/changes from different client alternately and you will find
that a client side cache is not always an advantage. Anyway...
>
> I will have to think about that.
... yes, ozone is more like an EJB server. One has to find out if one or the
other product/architecture is better for every new project. Exactly for this
reason I always answer performance questions, like you asked, the same way: the
only way to find out if one or the other product/architecture is suited for
your needs, you have to make a (very) small prototype and test (and compare) it
in your particular environment.
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com