I'm again revisiting an issue posted to this list around Oct 10, 2008.
Unfortunately I have never been able to solve this issue.
I used a stopwatch just now to time how long it takes to load the next
page when I click on "All Events" in OTRS. It was 55 seconds. In my
original posting I hadn't timed it with a stopwatch, I was reporting
what the droids told me - apparently they exaggerated a bit.
Regardless, the issue persists, and 55 seconds is far too long for as
few events as our calendar contains. I am open to whatever suggestions
anybody has regarding how to improve performance of the Calendar module!
Thank you in advance :)
CentOS 5.2, all updates applied
OTRS 2.3.3
Apache 2.2.3-11.el5_2
Perl 5.8.8-15.el5_2.1
mod_perl 2.0.2-6.3
mysql-server 5.0.45-7.el5
httpd.conf:
<-- snip -->
# load all otrs modules
Perlrequire /opt/otrs/scripts/apache2-perl-startup.pl
# Apache::Reload - Reload Perl Modules when Changed on Disk
PerlModule Apache2::Reload
PerlInitHandler Apache2::Reload
PerlModule Apache2::RequestRec
<Location /otrs>
ErrorDocument 403 /otrs/customer.pl
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
<-- snip -->
output of "top" while attempting to load the calendar:
top - 20:22:50 up 41 days, 14:39, 2 users, load average: 0.56, 0.29, 0.22
Tasks: 109 total, 2 running, 107 sleeping, 0 stopped, 0 zombie
Cpu(s): 45.2%us, 5.3%sy, 0.0%ni, 49.3%id, 0.0%wa, 0.0%hi, 0.2%si,
0.0%st
Mem: 4058316k total, 3817804k used, 240512k free, 172192k buffers
Swap: 2097144k total, 100k used, 2097044k free, 2820300k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2793 apache 25 0 95356 67m 6068 R 96 1.7 0:45.56 httpd
Interestingly I had not noted the high CPU usage of HTTPD while loading
this page in the past, but I repeated the test several times - httpd
uses almost no CPU unless the calendar is loading, at which time it
spikes one of the CPU cores to full load.
ORIGINAL THREAD FOLLOWS
>Nils Breunese (Lemonbit) wrote:
>> Nick Bright wrote:
>>
>>> I'm using OTRS on a CentOS 5 server, with mod_perl enabled. Overall
>>> OTRS got MUCH faster when I enabled the mod_perl configuration, but
>>> the calendar is still excruciatingly slow.
>>>
>>> That is to say, when you click on the "Calendar" icon it takes three
>>> to five minutes to pull up any given view of the Calendar.
>>>
>>> Is there any way to improve the performance of this application?
>>
>> We don't use the Calendar, but 3-5 *minutes* doesn't sound like >normal
>> performance (even when not using mod_perl). Have you checked things
>like
>> logs, system load, memory usage, etc.?
>
>Thanks for your response Nils.
>
>The server itself is performing well. CPU load is normal, memory load
>was normal, even before I upgraded the box to 4GB RAM (from 512MB). >Disk
>I/O doesn't seem unusually high, and "top" doesn't show the system
>spending a lot of time in wait state:
>
>Tasks: 104 total, 1 running, 102 sleeping, 0 stopped, 1 zombie
>Cpu(s): 0.2%us, 0.5%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si,
>0.0%st
>Mem: 4058316k total, 3791304k used, 267012k free, 180420k >buffers
>Swap: 2097144k total, 100k used, 2097044k free, 3058580k cached
>
>Even before switching the rest of OTRS to mod_perl, the calendar was
>slower than everything else. mod_perl made a *huge* difference in the
>rest of OTRS though. I'd have to subjectively say something like a 5x
>performance improvement.
>
>I tried putting the Calendar modules in to the mod_perl startup scripts
>but I don't think I was doing it right. I got lots of errors where
>apache wouldn't start, and when it would start it made no difference at
>all in performance.
>
>>
>> Nils Breunese.
>
>
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW!
http://www.otrs.com/en/support/enterprise-subscription/
