[rt-users] Other performance optimizations

[Steve Poirier]

Hello, Yes thats true.. My script was first intended for a in-house use, but
i saw a lot of people who needed that kind of script, so I published the
first draft, it does the job. It was, btw, my first experience with DBD. If
you really need 'high-performance' than this script can serve as a guide for
the db structure about deleting tickets. I'll continue to post scripts we
write or improve for our company on this list because i like to contribute
back to rt, but i really don't think that a prepare statement, separeted
from one line of the execute statement will slow down your script, except if
you own a 386 with 2 megs of edo ram ;-) kidding...

Best regards,

Steve

----- Original Message -----
From: "David C. Troy" <dave at toad.net>
To: <rt-users at lists.fsck.com>
Sent: Thursday, August 23, 2001 1:13 PM
Subject: Re: [rt-users] Other performance optimizations


>
> Steve -- one other thing.
>
> In your delete_dead_tickets.pl script, you might try using:
>
> $dbh->do($SQL);
>
> for your DELETE statements rather than the $dbh->prepare/execute combo --
> it's quicker and you can use it as long as you are not returning a
> recordset.
>
> Dave
>
> =====================================================================
> David C. Troy   [dave at toad.net]                   410-544-6193 Sales
> ToadNet - Want to go fast?                        410-544-1329 FAX
> 570 Ritchie Highway, Severna Park, MD 21146-2925  www.toad.net
>
> On Thu, 23 Aug 2001, David C. Troy wrote:
>
> >
> > A couple of other performance optimizations have come to mind that
perhaps
> > could be integrated:
> >
> >  -- Use syslog facilities for logging; writing a separate file for every
> > single instance of RT seems really ludicrous
> >
> >  -- Better utilize Use vs. Require in Perl to provide for mod_perl
startup
> > optimizations -- someone else addressed this a week or so ago
> >
> >  -- Generally minimize RT process startup overhead by reducing what is
> > loaded on a per-request basis
> >
> > While optimizing databases and creating additional indexes has helped
> > performance immensely, I still think it could be zippier.  And of course
> > isolating this darned segfault problem may be symptomatic of the need
for
> > some of these optimizations, or may lead to some other improvement.
> >
> > Dave
> >
> > =====================================================================
> > David C. Troy   [dave at toad.net]                   410-544-6193 Sales
> > ToadNet - Want to go fast?                        410-544-1329 FAX
> > 570 Ritchie Highway, Severna Park, MD 21146-2925  www.toad.net
> >
> >
> > _______________________________________________
> > rt-users mailing list
> > rt-users at lists.fsck.com
> > http://lists.fsck.com/mailman/listinfo/rt-users
> >
>
>
> _______________________________________________
> rt-users mailing list
> rt-users at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-users
>