Every click on a ticket takes 10 seconds

When clicking on a ticket, it takes 10 sec for the page to build up. The left
column of the site (the basics, people, more about xxx xxx) builds up in
under 1 sec, but the right column and the bottom (reminders, dates, links,
history) takes every time 9-10 seconds to show up.

Apache log with request time:
xxx.xxx.xxx.xxx - - [31/Jan/2008:04:01:27 -0500] “GET
/Ticket/Display.html?id=5335 HTTP/1.1” 200 282977 “http://xxxxxx.xx/
“Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127
Firefox/2.0.0.11” 9597932

The box has enough free ram, and is 99% idle. In the MySQL I can see many
locks like this:

Query_time: 9 Lock_time: 0 Rows_sent: 1 Rows_examined: 0

SELECT GET_LOCK(‘Apache-Session-bbe05f8fb2d2792dfb16441a94e7f351’, 3600);

This locks seems not the be the source of the problem but the consequence.
I switched temporarily to file system based sessions, but the behavior was
the same. Every click on a ticket took near 10 seconds.

The installation holds a few tickets and there are 3 people using it.

While the site builds up I can see that libperl.so takes 80% of the CPU
time.

Versions:

OS: CentOS 5
Apache/2.2.3
MySQL 5.0.22
Perl 5.8.8
RT: 3.6.6 (problem existed in 3.6.5 too)
SELinux: disabled

Could anyone please help me in debugging this problem?

Best regards

Adalbert
View this message in context: http://www.nabble.com/Every-click-on-a-ticket-takes-10-seconds-tp15200974p15200974.html

I do think you should see something in mysql slow log except those LOCKs.On Fri, Feb 8, 2008 at 5:26 PM, asklorz as@dunkel.de wrote:

When clicking on a ticket, it takes 10 sec for the page to build up. The left
column of the site (the basics, people, more about xxx xxx) builds up in
under 1 sec, but the right column and the bottom (reminders, dates, links,
history) takes every time 9-10 seconds to show up.

Apache log with request time:
xxx.xxx.xxx.xxx - - [31/Jan/2008:04:01:27 -0500] “GET
/Ticket/Display.html?id=5335 HTTP/1.1” 200 282977 “http://xxxxxx.xx/
“Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127
Firefox/2.0.0.11” 9597932

The box has enough free ram, and is 99% idle. In the MySQL I can see many
locks like this:

Query_time: 9 Lock_time: 0 Rows_sent: 1 Rows_examined: 0

SELECT GET_LOCK(‘Apache-Session-bbe05f8fb2d2792dfb16441a94e7f351’, 3600);

This locks seems not the be the source of the problem but the consequence.
I switched temporarily to file system based sessions, but the behavior was
the same. Every click on a ticket took near 10 seconds.

The installation holds a few tickets and there are 3 people using it.

While the site builds up I can see that libperl.so takes 80% of the CPU
time.

Versions:

OS: CentOS 5
Apache/2.2.3
MySQL 5.0.22
Perl 5.8.8
RT: 3.6.6 (problem existed in 3.6.5 too)
SELinux: disabled

Could anyone please help me in debugging this problem?

Best regards

Adalbert

View this message in context: http://www.nabble.com/Every-click-on-a-ticket-takes-10-seconds-tp15200974p15200974.html
Sent from the Request Tracker - User mailing list archive at Nabble.com.


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

Ruslan Zakirov-2 wrote:

I do think you should see something in mysql slow log except those LOCKs.

Thanks for the answer.

No there are no other slow queries.

But I could narrow this problem down to the users. I had a mail conversation
with Jesse Vincent. Please see below.

So this seems to be the problem. The “Reminders” frame has an owner dropdown
where all users are listed.

Anyone know to to disable this?

Hello,

I have some updates regarding thes case.

It seems the number of users caused the problem.
When a spam mail arrives a user wil be generated on the system, so
there were about 45000 users on the system. After deleting the
“spam” users 120 remained. Now the performance is good.

So it seems the application has performance problems when there are
many users.

45000 users shouldn’t be a problem. Likely you have an ACL setup that
listed all those spam users in one of the ownership dropdowns.

I hope this helps finding and resolving the problem.

Best regards

Adalbert Sklorz

View this message in context: http://www.nabble.com/Every-click-on-a-ticket-takes-10-seconds-tp15200974p15855507.html