Hi all, We're experiencing an issue with RT 3.6.1 wherein loading merged tickets results in severe performance degredation, e.g. 100 - 300 seconds per ticket. After 30 seconds, Apache gives up on the FastCGI script and generates a 500. This problem has been documented and referenced in several posts, but I have been unable to find a resolution. The following from Jesse seems to be the most descriptive:
"Yep. it's not recursion. It's RT::Transaction::TicketObj which should be made smarter. Rather than loading a ticket by id, it should be loading by id _and_ effective id. I'd love a patch." (Full thread is available at the Gossamer list archive: http://www.gossamer-threads.com/lists/rt/users/72384.) I checked 3.8.1 and the "TODO" is still present in Ticket_Overlay.pm (Load) so I'm assuming the performance problem is still present in that release. I'd love to help by producing a patch but frankly I don't understand what needs to be done. Has anyone else found a solution to this problem? Following another suggestion, I tried reducing the loglevel such that the "We found a merged ticket" messages weren't stored but we're still seeing occasional CPU spikes from the FastCGI process (and the associated delays which lead to HTTP/500s from Apache). Without the debug messages turned on I can't be absolutely certain the issue is loading merged tickets, but it seems very likely given that I can reproduce the problem by attempting to load a known-merged ticket with debug logging turned off. Thanks for any suggestions or feedback. Regards, Damon -- Damon T. Miller Director of Application Services Thinking Phone Networks [EMAIL PROTECTED] 617-649-1388 (Office) _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
