This seems like a mysql issue to me, not based on any particular
evidence though. I disagree that subsequent fetches should
be faster necessarily, because: a) with mod_perl, you may hit
a different apache child each request, and that child may
not have anything cached, and b) The ticket info could
change between hits, due to incoming mail or some other user,
so that RT may need to re-fetch each time to be sure.
This is a test system. The data does not change. This keeps my variables
down while testing.
I know that mysql can use several different backends, e.g.
isam, heap, myisam, innodb, bdb, all on a per-table basis.
This, and certainly indices, can affect you greatly.
Is it possible that in moving the data between mysql
versions, you have somehow dropped some indices?
Possibly, but I don’t think so.
And just to play devil’s advocate, are there any non-RT
network or apache issues? That is, I assume you can
display a static html page in much less than 5 secs?
The script runs from the rt3 server itself. The login page comes up in under
.5 seconds.
I just made another post, probably while you were writing yours, that moving
from the dual PII/512MB RAM/SCSI disk to a single Athlon 800/512MB RAM/IDE
disk resulted in the response time (when opening an existing ticket) going
from 16-17 seconds to 6-7 seconds. So at this point I am looking at the CPU
as the problem.
I would have thought (and hoped) that the PII 333Mhz would have fared better
than this.