RT Optimizations

I’m running RT 3.0.1 on Mac OS X 10.2.5, Mysql 4.0.12, Apache 1.3.27, modperl
1.27, perl 5.8.0. The box itself is a G4 800, with a gig of ram.

The home screen of RT loads quite slowly. Once in, I can access tickets quickly,
but the home screen takes at least a minute to load. I know it won’t be fast the
first time, as RT has to compile, but the home screen is still slow each
subsequent time.

I’ve applied the following optimizations to mysql. It starts with these options:

key_buffer=64M
table_cache=256
sort_buffer=4M
read_buffer_size=1M

It has these indices:

alter table Tickets add INDEX TypeINDEX(Type);
alter table Tickets add INDEX StatusINDEX(Status);
alter table Groups add INDEX DomainINDEX(Domain);
alter table Groups add INDEX InstanceINDEX(Instance);
alter table Groups add INDEX TypeINDEX(Type);
alter table Principals add INDEX PrincipalsINDEX(PrincipalType);
alter table CachedGroupMembers add INDEX GroupIdINDEX(GroupId);
alter table CachedGroupMembers add INDEX MemberIdINDEX(MemberId);
alter table Transactions ADD INDEX TicketIndex(Ticket);
alter table Transactions ADD INDEX EffectiveTicketIndex(EffectiveTicket);
alter table Transactions ADD INDEX CreatorIndex(Creator);
alter table Attachments ADD INDEX CreatorIndex(Creator);
alter table Attachments add index ParentIndex(Parent);
alter table Attachments ADD INDEX TransactionId(TransactionId);
alter table Tickets ADD INDEX EffectiveIdIndex(EffectiveId);
alter table Tickets ADD INDEX OwnerIndex(Owner);
alter table Tickets ADD INDEX CreatorIndex(Creator);

Apache has these settings in httpd.conf (among others, these are just the
relevant ones)

MinSpareServers 5
MaxSpareServers 5
MaxClients 10

Any suggestions on further optimizations? I’ve enabled the slow query log in
mysql.conf, but have yet to see it appear. The machine is certainly beefy enough
to run RT with our small number of tickets (<15K, most of which is spam). Might
deleting the spam help? Does anyone have a copy of delete_dead_tickets.pl ?

Many thanks,

Josh Levinger
Dartware, LLC

Question: When you say you can access tickets quickly, what sort of per
ticket times are you seeing? If you add a Debug=1 at the end of the url
in the cgi-params RT will print out how long the page took at the bottom
of the page.

I’m just curious what other people are seeing, as my very small site sees
3 seconds for the simplest tickets, and upwards of 10 for tickets that
people have gone back and forth on a few times.

I’m not sure if it’ll buy you a whole lot, you might try enabling Mason’s
’static_source’. Enabling static_source will prevent mason from trying to
recompile each page & it’s children every few minutes. You can enable it
in RT/Interfaces/Web.pm in NewApacheHandler() by adding:

'static_source' => 1,  

Just after 'args_method=>“CGI”

Matt

I’m running RT 3.0.1 on Mac OS X 10.2.5, Mysql 4.0.12, Apache 1.3.27, modperl
1.27, perl 5.8.0. The box itself is a G4 800, with a gig of ram.

The home screen of RT loads quite slowly. Once in, I can access tickets quickly,
but the home screen takes at least a minute to load. I know it won’t be fast the
first time, as RT has to compile, but the home screen is still slow each
subsequent time.

How many queues do you have? How many staff users? Your setup is very,
very similar to my testing setup. (My tiBook is a bit faster, but
probablz has a slower disk :wink: As I’m in a net-cafe, I can’t quote my
mysql config at you, but I pretty much never see the front page take
more than 15s to load, even with heavy ticket loads…

j

I’ve applied the following optimizations to mysql. It starts with these options:

key_buffer=64M
table_cache=256
sort_buffer=4M
read_buffer_size=1M

It has these indices:

alter table Tickets add INDEX TypeINDEX(Type);
alter table Tickets add INDEX StatusINDEX(Status);
alter table Groups add INDEX DomainINDEX(Domain);
alter table Groups add INDEX InstanceINDEX(Instance);
alter table Groups add INDEX TypeINDEX(Type);
alter table Principals add INDEX PrincipalsINDEX(PrincipalType);
alter table CachedGroupMembers add INDEX GroupIdINDEX(GroupId);
alter table CachedGroupMembers add INDEX MemberIdINDEX(MemberId);
alter table Transactions ADD INDEX TicketIndex(Ticket);
alter table Transactions ADD INDEX EffectiveTicketIndex(EffectiveTicket);
alter table Transactions ADD INDEX CreatorIndex(Creator);
alter table Attachments ADD INDEX CreatorIndex(Creator);
alter table Attachments add index ParentIndex(Parent);
alter table Attachments ADD INDEX TransactionId(TransactionId);
alter table Tickets ADD INDEX EffectiveIdIndex(EffectiveId);
alter table Tickets ADD INDEX OwnerIndex(Owner);
alter table Tickets ADD INDEX CreatorIndex(Creator);

Apache has these settings in httpd.conf (among others, these are just the
relevant ones)

MinSpareServers 5
MaxSpareServers 5
MaxClients 10

Any suggestions on further optimizations? I’ve enabled the slow query log in
mysql.conf, but have yet to see it appear. The machine is certainly beefy enough
to run RT with our small number of tickets (<15K, most of which is spam). Might
deleting the spam help? Does anyone have a copy of delete_dead_tickets.pl ?

Many thanks,


Josh Levinger
Dartware, LLC


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

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

I have six queues, of which only two are heavily used. Ten users, of whom no
more than four usually connect at the same time, hence the MaxClients 10 in
httpd.conf.

I currently get around 45 seconds to display a queue, 55 seconds to display the
home screen, and between 5 and 15 seconds for a ticket.

I enabled static source and didn’t notice any substantial change.

Would running delete_dead_tickets.pl help? Is it still safe on RT3?

Thanks for the help.

Josh Levinger

It would be helpful if you could turn on database logging and see what
of all that is actually taking a long time.On Thu, May 08, 2003 at 12:26:33PM -0400, Josh Levinger wrote:

I have six queues, of which only two are heavily used. Ten users, of whom no
more than four usually connect at the same time, hence the MaxClients 10 in
httpd.conf.

I currently get around 45 seconds to display a queue, 55 seconds to display the
home screen, and between 5 and 15 seconds for a ticket.

I enabled static source and didn’t notice any substantial change.

Would running delete_dead_tickets.pl help? Is it still safe on RT3?

Thanks for the help.

Josh Levinger


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

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

Hi all,— Jesse Vincent jesse@bestpractical.com wrote:

It would be helpful if you could turn on database logging and see what
of all that is actually taking a long time.

I may confirm that it’s rather slow. We’re running the previous pre-release
with Atrijus’ mail autohandler patch, Sun Ultra II 400 Mhz, 256 Mb RAM.
We limited the number of Apache processes, so RAM is not much of an issue.

A ticket display, with less than 10 correspondence messages in it, takes
approx. 10-15 seconds, and “top” shows Apache taking most of the CPU time, not
the mysql process.

Login screen and the queue overview is rather slow, comparable to 5 seconds.
Configuration options menu is quite fast, 1-2 seconds responding time.

Apache is also encrypting the output with mod_ssl, so it’s difficult to say
what exactly slows it down.

Unfortunately, I can’t tell more right now, will play with it next week.

Regards,
Stan

Hi all,

It would be helpful if you could turn on database logging and see what
of all that is actually taking a long time.

I may confirm that it’s rather slow. We’re running the previous pre-release
with Atrijus’ mail autohandler patch, Sun Ultra II 400 Mhz, 256 Mb RAM.
We limited the number of Apache processes, so RAM is not much of an issue.

now we’ve upgraded RAM up to 1GB.

Upgrading from 3.0.2pre4 to pre6, with Searchbuilder 0.81, didn’t much
improve:

the home page with 10 ticket subjects (I own… I requested…) is loaded in 4-5
seconds.

Ticket display (11 correspomdence parts and 2 file attachments) takes 11-13 seconds.

Mysql process doesn’t take more than 2% of the CPU time, the rest is taken by the
Apache httpd.

I’ll be glad to make more tests if you give me a clue what can be tested.

Regards,
Stan

with Atrijus’ mail autohandler patch, Sun Ultra II 400 Mhz, 256 Mb RAM.
We limited the number of Apache processes, so RAM is not much of an issue.

now we’ve upgraded RAM up to 1GB.

Activating the MySQL Query Cache will help as well.

set-variable = query_cache_size=32M
set-variable = query_cache_type=1

Activating the MySQL Query Cache will help as well.

set-variable = query_cache_size=32M
set-variable = query_cache_type=1

This is supported in mysql 4.0.1, and we run 3.23.53.

Anyway, mysql daemon’s CPU time is less than 20% of Apache’s
time:

swamp:/usr/local/mysql # ps -Af | grep htt
root 4354 1 0 16:36:17 ? 0:00 /usr/local/apache-1.3.27/bin/httpd -DSSL
httpd 4355 4354 1 16:36:17 ? 0:01 /usr/local/apache-1.3.27/bin/httpd -DSSL
httpd 4356 4354 22 16:36:17 ? 0:12 /usr/local/apache-1.3.27/bin/httpd -DSSL
httpd 4358 4354 5 16:36:22 ? 0:04 /usr/local/apache-1.3.27/bin/httpd -DSSL
swamp:/usr/local/mysql # ps -Af | grep mysq
root 4273 1 0 16:32:33 pts/2 0:00 /bin/sh /usr/local/mysql/bin/safe_mysqld
–datadir=/data/wwwdata/mysql/mysqldat
mysql 4298 4273 0 16:32:33 pts/2 0:02 /usr/local/mysql/libexec/mysqld
–basedir=/usr/local/mysql --datadir=/data/wwwd

So, something has to be done to Perl code…

This is supported in mysql 4.0.1, and we run 3.23.53.

Mysql 4.0.13 is recommended for RT3. Give it lots of ram and let it
help you.

-R