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?
Tim To > -----Original Message----- > From: Tim Bunce [mailto:[EMAIL PROTECTED] > Sent: Friday, April 16, 2004 3:57 PM > To: Tim To > Cc: Reidy, Ron; Scott T. Hildreth; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > 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. > > Tim.
