Comment A couple notes... (Score 5, Informative) 194
What I did was to get a Jaunty _chroot_ running on the Kindle 2. The interesting bits were mostly around making X work and beating the 5-pad into submission.
What I did was to get a Jaunty _chroot_ running on the Kindle 2. The interesting bits were mostly around making X work and beating the 5-pad into submission.
Longstaff,
3 seconds to iterate over the queue list sounds _broken_. I know you're no longer with that employer, but I'd encourage anybody else running into performance issues like that to bring them up on The rt-users mailinglist. There are plenty of folks who've probably seen and work through whatever it is that you're running into. And I'd much rather get scalability issues aired publicly in an rt-related forum where the community can work together to improve matters than have multiple sysadmins, DBAs and programmers struggle in silence.
Readers might want to take my comments with a grain of salt, as I'm RT's original author and chief architect. I routinely work with clients with RT instances that are well over 100,000 tickets. When using any large application at scale, you're going to need to invest time in performance tuning, but 100k tickets isn't "big" for an RT instance. With a single front end box and a single backend (untuned, but beefy) DB server, I've seen an RT server doing 10,000 tickets on a slow day, bursting to 25,000 with several million in the database.
Variables don't; constants aren't.