Other performance optimizations

RT Users
1

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@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

2

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

The Log::Dispatch stuff really doesn’t deal well with syslog out of the box.
Or it didn’t when I last looked. If that’s changed, I’d be overjoyed to make
it an option

– Better utilize Use vs. Require in Perl to provide for mod_perl startup
optimizations – someone else addressed this a week or so ago

I went back and forth with Vivek off list about this. At this point
I’m pretty sure that RT is in fact properly preloading everything.

– Generally minimize RT process startup overhead by reducing what is
loaded on a per-request basis

Huh? What sorts of things?

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.

One of the biggies is implementing a certain kind of caching for multi-result
ticket queries. That would be rather a lot of work and only starts biting
high-volume users. Which I’m not likely to deal with, unless a client
is interested in having me do it.

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

3

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@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.netOn 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@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@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

4

I hacked RT so that the “real” groups (as opposed to pseudo groups) would
show in alphabetical order.

The following subroutine was added to lib/RT/Groups.pm:

# {{{ sub OrderAlpha

=head2 OrderAlpha

Alphabetizes group names.

=cut

  sub OrderAlpha {
    my $self = shift;

  # By default, order by name
    return ($self->OrderBy( ALIAS => 'main',
                  FIELD => 'Name',
                  ORDER => 'ASC'));

}
# }}}

Then, the line after the “Limit to Real” line was added to index.html in
WebRT/html/Admin/Groups:

my $Groups = new RT::Groups($session{'CurrentUser'});
$Groups->LimitToReal;

** $Groups->OrderAlpha;

</%INIT>

If you modify Groups.pm to add this feature, make sure you stop and
restart Apache so RT sees the change… Cheers…

			~ARK
5

Alternatively, you can add the

$self->OrderBy( ALIAS => ‘main’,
FIELD => ‘Name’,
ORDER => ‘ASC’);

call to the _Init subroutine. Which is what 2.0.6 will have :wink:

Thanks. I’ve been trying to catch the default ordering stuff. I’m starting to get there. but I’m not all the way yet. If there are other things that aren’t
sorted properly by default, I’d love to know.On Thu, Aug 23, 2001 at 05:28:47PM -0400, Ayan R. Kayal wrote:

I hacked RT so that the “real” groups (as opposed to pseudo groups) would
show in alphabetical order.

The following subroutine was added to lib/RT/Groups.pm:

{{{ sub OrderAlpha

=head2 OrderAlpha

Alphabetizes group names.

=cut

sub OrderAlpha {
  my $self = shift;

# By default, order by name
  return ($self->OrderBy( ALIAS => 'main',
                FIELD => 'Name',
                ORDER => 'ASC'));

}

}}}

Then, the line after the “Limit to Real” line was added to index.html in
WebRT/html/Admin/Groups:

my $Groups = new RT::Groups($session{‘CurrentUser’});
$Groups->LimitToReal;
** $Groups->OrderAlpha;

</%INIT>

If you modify Groups.pm to add this feature, make sure you stop and
restart Apache so RT sees the change… Cheers…

  		~ARK

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

6

I actually put it in _Init the first time, but then the Pseudogroups came
up alphabetized and that looked silly (I liked the original order). :slight_smile: I
guess I chose aesthetics over ease of implementation.On Thu, 23 Aug 2001, Jesse Vincent wrote:

Alternatively, you can add the

$self->OrderBy( ALIAS => ‘main’,
FIELD => ‘Name’,
ORDER => ‘ASC’);

call to the _Init subroutine. Which is what 2.0.6 will have :wink:

Thanks. I’ve been trying to catch the default ordering stuff. I’m starting to get there. but I’m not all the way yet. If there are other things that aren’t
sorted properly by default, I’d love to know.

On Thu, Aug 23, 2001 at 05:28:47PM -0400, Ayan R. Kayal wrote:

I hacked RT so that the “real” groups (as opposed to pseudo groups) would
show in alphabetical order.

The following subroutine was added to lib/RT/Groups.pm:

# {{{ sub OrderAlpha

=head2 OrderAlpha

Alphabetizes group names.

=cut

sub OrderAlpha {
  my $self = shift;

# By default, order by name
  return ($self->OrderBy( ALIAS => 'main',
                FIELD => 'Name',
                ORDER => 'ASC'));

}
# }}}

Then, the line after the “Limit to Real” line was added to index.html in
WebRT/html/Admin/Groups:

my $Groups = new RT::Groups($session{'CurrentUser'});
$Groups->LimitToReal;

** $Groups->OrderAlpha;

</%INIT>

If you modify Groups.pm to add this feature, make sure you stop and
restart Apache so RT sees the change… Cheers…

  		~ARK
7

nod The goal of doing the default Alphabetical sort order is so that
the default sort is predictable. because there’s no real guarantee that the
DB will return results in insertion order. I’d be happy to take a patch
to sort the PseudoGroups by another criterion within the webui.

-jOn Thu, Aug 23, 2001 at 07:18:48PM -0400, Ayan R. Kayal wrote:

I actually put it in _Init the first time, but then the Pseudogroups came
up alphabetized and that looked silly (I liked the original order). :slight_smile: I
guess I chose aesthetics over ease of implementation.

On Thu, 23 Aug 2001, Jesse Vincent wrote:

Alternatively, you can add the

$self->OrderBy( ALIAS => ‘main’,
FIELD => ‘Name’,
ORDER => ‘ASC’);

call to the _Init subroutine. Which is what 2.0.6 will have :wink:

Thanks. I’ve been trying to catch the default ordering stuff. I’m starting to get there. but I’m not all the way yet. If there are other things that aren’t
sorted properly by default, I’d love to know.

On Thu, Aug 23, 2001 at 05:28:47PM -0400, Ayan R. Kayal wrote:

I hacked RT so that the “real” groups (as opposed to pseudo groups) would
show in alphabetical order.

The following subroutine was added to lib/RT/Groups.pm:

# {{{ sub OrderAlpha

=head2 OrderAlpha

Alphabetizes group names.

=cut

sub OrderAlpha {
  my $self = shift;

# By default, order by name
  return ($self->OrderBy( ALIAS => 'main',
                FIELD => 'Name',
                ORDER => 'ASC'));

}
# }}}

Then, the line after the “Limit to Real” line was added to index.html in
WebRT/html/Admin/Groups:

my $Groups = new RT::Groups($session{'CurrentUser'});
$Groups->LimitToReal;

** $Groups->OrderAlpha;

</%INIT>

If you modify Groups.pm to add this feature, make sure you stop and
restart Apache so RT sees the change… Cheers…

  		~ARK

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

8

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 :wink: kidding…

Best regards,

SteveFrom: “David C. Troy” dave@toad.net
To: rt-users@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@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

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@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@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users