RE: performance problem with dbd oracle
From: Tim To (tto_at_redback.com)
To: "Tim Bunce" <Tim.Bunce@pobox.com> Date: Fri, 16 Apr 2004 16:22:54 -0700
Thanks Tim I will try that.
I am running all these tests on the same server - does the network latency
still apply? What else can I provide to get more help? Basically the app and
the environment didn't change I just ported everything from linux mysql to
oracle Solaris and we didn't see the performance problem with that combo.
Shouldn't network latency have affect DBD::mysql also?
> -----Original Message-----
> From: Tim Bunce [mailto:Tim.Bunce@pobox.com]
> Sent: Friday, April 16, 2004 3:57 PM
> To: Tim To
> Cc: Reidy, Ron; Scott T. Hildreth; firstname.lastname@example.org;
> Subject: Re: performance problem with dbd oracle
> On Fri, Apr 16, 2004 at 11:07:04AM -0700, Tim To wrote:
> > The performance problem is actually worse with the real app which I have
> > ported from Linux mysql to Solaris oracle. The worst of the
> statements is
> > executing a commit after three or so insert/update statement so
> I've created
> > a couple of insert only test scripts for comparison(That's when the five
> > times slowdown was noticed). They both do the same thing but one's an
> > anonymous block in pl/sql and the other's using perl
> DBI/DBD::oracle hence
> > through OCI.
> > Using sqlloader is not feasible here since I'm just trying to
> > isolate the performance problem with the real app and not
> really trying to
> > do bulk load alone. At this point I'm more interested to see if
> anyone have
> > used dbd/dbi with oracle 9i and do they have any performance
> problem similar
> > to what I'm seeing. And if available what's the solution.
> The 'problem' is simply the extra time it takes for each execute
> request to get from the client to the server and for the result
> packet to get back: Latency.
> The pl/sql version just ships the whole code to the server and
> executes it with one request.
> You could just take the "anonymous block in pl/sql" and put it in
> a $dbh->do(...) statement (without the leading "set"s and
> training "/exit")
> and you'll find the speed is the same :)
> Without knowing more about what the real application is doing (not this
> very artificial test) it's hard to help more.