Performance issues with 3.6.6 upgrade

We’re testing an upgrade from 3.6.4 to 3.6.6 and have noticed that
interactive response time on 3.6.6 is much slower than 3.6.4. Using the
exact same hardware, OS, and MySQL db - most screens (ie; at a glance,
ticket display) take less than 0.5 seconds when using 3.6.4 and 3 or
more seconds on 3.6.6.

We’re using CentOS 5.1, perl 5.8.8, apache 2.2.3, MySQL 5.0.22.

Any suggestions on where to start in troubleshooting this?

We’re testing an upgrade from 3.6.4 to 3.6.6 and have noticed that
interactive response time on 3.6.6 is much slower than 3.6.4. Using the
exact same hardware, OS, and MySQL db - most screens (ie; at a glance,
ticket display) take less than 0.5 seconds when using 3.6.4 and 3 or
more seconds on 3.6.6.

We’re using CentOS 5.1, perl 5.8.8, apache 2.2.3, MySQL 5.0.22.

Any suggestions on where to start in troubleshooting this?

I may not have the version right, but try upgrading MySQL to 5.0.45
or higher. Check the list for a discussion of performance problems
with 5.0 and minor version < 45.

Ken

We’re testing an upgrade from 3.6.4 to 3.6.6 and have noticed that
interactive response time on 3.6.6 is much slower than 3.6.4. Using
the
exact same hardware, OS, and MySQL db - most screens (ie; at a glance,
ticket display) take less than 0.5 seconds when using 3.6.4 and 3 or
more seconds on 3.6.6.

I have a sneaking suspicion it’s related to bugs in the older 5.0.x
mysql you’re running. But what does your slow query log say?

We’re testing an upgrade from 3.6.4 to 3.6.6 and have noticed that
interactive response time on 3.6.6 is much slower than 3.6.4. Using
the exact same hardware, OS, and MySQL db - most screens (ie; at a
glance, ticket display) take less than 0.5 seconds when using 3.6.4
and 3 or more seconds on 3.6.6.

I have a sneaking suspicion it’s related to bugs in the older 5.0.x
mysql you’re running. But what does your slow query log say?

Based on this and the note from Ken Marshall, I upgraded to MySQL
5.0.51a. The speed is a little better (1.5 to 2 sec) as noted by the
"Time to display" at the bottom of the screen, but the actual wall clock
time is still several times that. Initial log in displays a time at the
bottom of 2 seconds maybe, but the actual time for the system to display
anything in the browser is over a minute. If I switch back to 3.6.4,
everything is done a fraction of a second. Slow query log has nothing
except startup messages in it under both 3.6.4 and 3.6.6.

We’re testing an upgrade from 3.6.4 to 3.6.6 and have noticed that
interactive response time on 3.6.6 is much slower than 3.6.4. Using
the exact same hardware, OS, and MySQL db - most screens (ie; at a
glance, ticket display) take less than 0.5 seconds when using 3.6.4
and 3 or more seconds on 3.6.6.

I have a sneaking suspicion it’s related to bugs in the older 5.0.x
mysql you’re running. But what does your slow query log say?

Based on this and the note from Ken Marshall, I upgraded to MySQL
5.0.51a. The speed is a little better (1.5 to 2 sec) as noted by the
"Time to display" at the bottom of the screen, but the actual wall clock
time is still several times that. Initial log in displays a time at the
bottom of 2 seconds maybe, but the actual time for the system to display
anything in the browser is over a minute. If I switch back to 3.6.4,
everything is done a fraction of a second. Slow query log has nothing
except startup messages in it under both 3.6.4 and 3.6.6.

Rob,

The time at the bottom of the page is calculated when the page
is presented by the RT server. The additional time I am assuming
is time spent in the browser rendering the page. I wonder what
changes were made between 3.6.4 and 3.6.6 that slowed the rendering
so dramatically. We are getting ready to upgrade to the 3.6.x
series and I would like to be able to use the latest release. Maybe
Jesse has some ideas.

Cheers,
Ken

We’re testing an upgrade from 3.6.4 to 3.6.6 and have noticed
that

interactive response time on 3.6.6 is much slower than 3.6.4.
Using the exact same hardware, OS, and MySQL db - most screens
(ie; at a glance, ticket display) take less than 0.5 seconds
when

using 3.6.4 and 3 or more seconds on 3.6.6.

I have a sneaking suspicion it’s related to bugs in the older
5.0.x

mysql you’re running. But what does your slow query log say?

Based on this and the note from Ken Marshall, I upgraded to MySQL
5.0.51a. The speed is a little better (1.5 to 2 sec) as noted by the

“Time to display” at the bottom of the screen, but the actual wall
clock time is still several times that. Initial log in displays a
time

at the bottom of 2 seconds maybe, but the actual time for the system

to display anything in the browser is over a minute. If I switch
back

to 3.6.4, everything is done a fraction of a second. Slow query log
has nothing except startup messages in it under both 3.6.4 and
3.6.6.

Rob,

The time at the bottom of the page is calculated when the page is
presented by the RT server. The additional time I am assuming is time
spent in the browser rendering the page. I wonder what changes were made
between 3.6.4 and 3.6.6 that slowed the rendering so dramatically. We
are getting ready to upgrade to the 3.6.x series and I would like to be
able to use the latest release. Maybe Jesse has some ideas.

Cheers,
Ken

Ken, thanks very much for the info. I don’t think it’s the browser
though; I can see the httpd process using 100% cpu while waiting for the
page, tcpdump shows there’s no data going to the browser for most of
this time. Not sure what it’s up to at that time, nothing interesting in
the apache logs. I’ve gone back to 3.6.4, which is working well.

Rob