[rt-users] Re: [Rt-devel] Performance issues with RT3 (all versions)

Leon rt at tux.datalink.co.za
Tue Aug 3 15:09:49 EDT 2004


I have also had major issues with performance.  We have a quad Xeon with 
a 1 gig ram, and 15000RPM SCSI drives, that we use for development. We 
have about 2000 tickets on our system and  the attachments table is 
about 100 to 150  megs already. We are also using FastCGI,Apache MySQL 4 
, RT 3.2.1.

When I run IE against RT it sometimes take up to a minute before the 
ticket is shown.
I have tried Firefox and found that as the info is retrieved fro the DB, 
it is displayed. The header will sometime appear a bit slow ( about 5 to 
10 seconds) and then the rest of the info comes through one reply or 
comment at a time. Still taking about 30 to 40 seconds. When running  
top I can see the MasonHandler.fcgi runs at 99% for the duration of the 
ticket retrieval.
If another session tries to retrieve a ticket at the some time the 
duration of all the ticket retrievals increase.

I have applied the Fast CGI and MYSQL config changes in the WIKIs and no 
real improvements.

Leon
Jon Masters wrote:

> Hi all,
>
> For quite some time we have been running RT3 to track support issues, 
> following my recommendation of the software. Although various 
> configurations have been used, I am currently debugging an instance 
> running on a Debian testing box with the specification below because 
> the faster production machine (running Mandrake release 9) cannot be 
> tinkered with for the moment and performace problems plague both.
>
> Performance is...well horrible. Painfully unpleasant and this is not 
> with the 40,000 tickets quoted in RT documentation. This is with a 
> database not exceeding about 50-100MB in size and with only a handfull 
> of tickets in it. In other words there are almost no tickets.
>
> I have tried various different configurations based around RT3 
> (various versions including but not limited to 3.2.0), MySQL 4, and 
> Apache 1 and 2 running every possible configuration of mod_perl 1,2 
> and FastCGI. Essentially I have tried every possible choice available.
>
> Query time is so painful that the people here are having to resort to 
> using regular email and just have RT keep a copy for auditing. I do 
> unfortunately not have time to delve much in to the bowls of RT (I do 
> embedded Linux kernel hacking and am not usually a perl person) but 
> have installed various different profiling options in Apache to at 
> least give a feel for where this is falling over. I have debug traces 
> of apache and various other output here and am willing to provide 
> various additional information and test solutions if I can help to 
> correct this issue.
>
> Clearly the testing machine is not the fastest in the world but it is 
> an order of magnitude too slow and there is something more fundamental 
> at fault here. It does not look like MySQL is at fault - it looks like 
> it is SearchBuilder spewing out way too many searches or something. As 
> I have read on your mailing list archives and on other online lists, 
> numerous people report problems with attachments - some of these 
> tickets have large numbers of attachments but not all, and even then 
> even listing the queue takes nearly all day.
>
> I am not trying to rant here but there is clearly something very weird 
> going on which I would like to help you guys to fix. You never know, 
> it might even be possible to convince me that perl isn't such a slow 
> scripting language after all.
>
> Cheers,
>
> Jon.
>
> --- Specification ---
>
> Linux kernel 2.6.6 (Not stock, Debian kernel release 2.6.6-1-686) 
> running on an Intel Celeron 600MHz CPU. This test box is not the 
> fastest machine in the world but it runs nothing else other than RT 
> and a few general system daemons. No windowing system cruft. System 
> has been tuned using sysctls and ulimits adjusted all in vain, IDE DMA 
> is on, etc. etc. The production machine exhibits the same problems and 
> is much faster.
>
> (So please assume that the base Debian is configured correctly).
>
> To the system has been added MySQL version 4.0.18 (Debian 4.0.18-5).
>
> I have also installed RT 3.2.0 as well as other versions.
>
> I have performed database OPTIMIZE, ANALYZE, etc. etc.
>
> etc. etc. etc. etc.
>
> --- dprofpp output ---
>
> Storable::nfreeze has 1 unstacked calls in outer
> Storable::_freeze has 1 unstacked calls in outer
> Exporter::import has -2 unstacked calls in outer
> RT::Mason::handler has -1 unstacked calls in outer
> CGI::delete has 1 unstacked calls in outer
> AutoLoader::AUTOLOAD has -3 unstacked calls in outer
> Storable::thaw has 1 unstacked calls in outer
> Exporter::Heavy::heavy_export has 2 unstacked calls in outer
> Total Elapsed Time = 196.2333 Seconds
>   User+System Time = 72.21333 Seconds
> Exclusive Times
> %Time ExclSec CumulS #Calls sec/call Csec/c  Name
>  40.4   29.24 29.418   4647   0.0063 0.0063 
> DBIx::SearchBuilder::Record::__ANO
>                                              N__
>  9.20   6.641 71.487   2297   0.0029 0.0311  HTML::Mason::Request::comp
>  8.09   5.844  5.844  10197   0.0006 0.0006  HTML::Mason::Request::print
>  6.79   4.902  4.974     52   0.0943 0.0957 
> RT::Transaction::BriefDescription
>  6.58   4.753  4.805     41   0.1159 0.1172  
> RT::Attachment::ContentLength
>  4.35   3.139  3.178     25   0.1256 0.1271  RT::Attachment::Content
>  3.52   2.539  2.639     25   0.1016 0.1055  Text::Quoted::extract
>  2.28   1.644  1.658     41   0.0401 0.0404  RT::Attachment::Headers
>  1.65   1.195  1.211     53   0.0226 0.0228  RT::Transactions::Next
>  1.64   1.186  1.182     52   0.0228 0.0227  RT::Record::CreatedAsString
>  1.52   1.095  1.119     25   0.0438 0.0448  RT::Transaction::IsInbound
>  1.37   0.986  1.011     42   0.0235 0.0241  RT::Attachments::Next
>  0.97   0.697  0.695     50   0.0139 0.0139  RT::Transaction::TicketObj
>  0.87   0.628  0.635     52   0.0121 0.0122  RT::Record::CreatorObj
>  0.51   0.369  0.367     20   0.0184 0.0184 
> DBIx::SearchBuilder::Record::AUTOL
>                                              OAD
>
>
> _______________________________________________
> Rt-devel mailing list
> Rt-devel at lists.bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>
>



More information about the rt-users mailing list