Re: Help poor performance with Oraperl for perl5 (DBI Oraperl)

From: Tim Bunce <Tim.Bunce_at_ig.co.uk>
Date: 1998/01/20
Message-ID: <En3Mo9.MCr_at_ig.co.uk>#1/1


In article <885259713.215023618_at_dejanews.com>, <skleinma_at_interpath.com> wrote:
> I'm having the same problem. Opening a connection to Oracle is very fast
> (about 2/10ths of a second) as is the search. But the $cursor->fetch()
> loop is EXTREMELY slow. (About 1,000 rows per second.)

(That's fairly meaningless without query, row-width, platform, network and Oracle configuration and workload details.)

I'd be grateful if people who feel they have a problem with DBD::Oracle performance would report the details to the dbi-users mailing list.

Please include as of the above information as possible (and as concisely as possible :-). Thanks.

Tim.

> >In article <En1FEH.C0E_at_ig.co.uk>,
> > Tim Bunce <Tim.Bunce_at_ig.co.uk> wrote:
> >
> > In article <69j1gn$oop$1_at_rdsunx.crd.ge.com>,
> > Mark Kornfein <kornfein_at_.crd.ge.com> wrote:
> > >
> > > We have an application that we are developing using the Oraperl interface
> > > to DBI. (DBD-Oracle-0.47).
> > >
> > > After doing some timing tests we have found the queries have very poor
> > > perfromance. A query that takes 4-5 seconds to complete in sqlplus takes
> > > 50 seconds from perl. We have similiar ratios for other queries. The time is
> > > being spent in the fetch loop (not login or open).
> > >
> > > Also the query we are using is very simple "select x from table where y =2;"
> > > it does not contain a join and returns about 600 records 1 field each.
> >
> > I don't recall anyone reporting such performance problems for fetches
> > before. Thousands of users on many platforms have no such problems.
> >
> > > We have been told by folks who use Oraperl for perl 4, that we need to
> > > increase the cache size, but this is evidently not an option in DBI.
> >
> > DBD::Oracle 0.47 has a (very effective) row cache. Use $h->trace(2) to
> > see it in operation.
> >
> > Tim.
Received on Tue Jan 20 1998 - 00:00:00 CET

Original text of this message