Reply text box slow to load

We upgraded from 4.0.7 last night, and am noticing that when you reply to a
ticket, the reply text box takes the better part of 60 seconds to load. It
seems to be slightly better in Chrome than Firefox, but still takes
inordinately long. Has anyone else seen this problem?

:T

Thatcher Rea
ByWater Solutions
Support and Consulting for Open Source Software
Headquarters: Santa Barbara, CA
Phone/Fax # (888) 900-8944 ext. 1

What is Koha? http://bywatersolutions.com/what-is-koha/

If I set MessageBoxRichText to 0, the problem resolves itself. But that
means that I don’t have Rich Text editing capabilities in my ticket
replies. Any ideas?

:TOn Thu, Oct 31, 2013 at 7:20 AM, Thatcher Rea < thatcher.rea@bywatersolutions.com> wrote:

We upgraded from 4.0.7 last night, and am noticing that when you reply to
a ticket, the reply text box takes the better part of 60 seconds to load.
It seems to be slightly better in Chrome than Firefox, but still takes
inordinately long. Has anyone else seen this problem?

:T


Thatcher Rea
ByWater Solutions
Support and Consulting for Open Source Software
Headquarters: Santa Barbara, CA
Phone/Fax # (888) 900-8944 ext. 1
http://bywatersolutions.com
What is Koha? http://bywatersolutions.com/what-is-koha/

Thatcher Rea
ByWater Solutions
Support and Consulting for Open Source Software
Headquarters: Santa Barbara, CA
Phone/Fax # (888) 900-8944 ext. 1

What is Koha? http://bywatersolutions.com/what-is-koha/

If I set MessageBoxRichText to 0, the problem resolves itself. But that means that I don’t
have Rich Text editing capabilities in my ticket replies. Any ideas?

Something in your environment (but not our production instance, or any
other reported environment) is causing the JavaScript for the rich
text editor to load exceptionally slowly.

Ask Chrome what part is taking a long time and whether it’s the
delivery over the wire or the parsing.

-kevin> On Thu, Oct 31, 2013 at 7:20 AM, Thatcher Rea <[1]thatcher.rea@bywatersolutions.com> wrote:

 We upgraded from 4.0.7 last night, and am noticing that when you reply to a ticket, the
 reply text box takes the better part of 60 seconds to load. It seems to be slightly better
 in Chrome than Firefox, but still takes inordinately long. Has anyone else seen this
 problem?

Hi!

I have exactly the same problem. I’ve investigated the loading of the page with the WYSIWYG-editor and got the following results:

http://s22.postimg.org/wqo1j42r5/wysiwyg.png

Maybe this will help debugging this further?

After the initial load the future loads of that js will be cached and therefore much slower. And after the cache expiry (typically the next workday) you have to wait for another 30 seconds to get the WYSIWYG editor back up again.

  • Marius

I have exactly the same problem. I’ve investigated the loading of the page with the
WYSIWYG-editor and got the following results:

[1]http://s22.postimg.org/wqo1j42r5/wysiwyg.png

Maybe this will help debugging this further?

After the initial load the future loads of that js will be cached and therefore much slower.
And after the cache expiry (typically the next workday) you have to wait for another 30
seconds to get the WYSIWYG editor back up again.

While this confirms that something is taking a long time to load, the
consistent 15 seconds on each request is quite odd, especially since
larger files take mere milliseconds to download.

Are you using JSMin? How is your RT configured, etc, etc.
If you can replicate these timings on issues.bestpractical.com it
would be interesting.

-kevin

While this confirms that something is taking a long time to load,
the consistent 15 seconds on each request is quite odd, especially
since larger files take mere milliseconds to download.

Are you using JSMin? How is your RT configured, etc, etc. If you
can replicate these timings on issues.bestpractical.com it would be
interesting.

I’m not sure if I’m using JSMin… What is it? How do I determine that?

Basically what I did was upgrade from version 4.0.7 (the version
that’s included in Debian Squeeze) to 4.2.1 from source. So I then
just took the database from that Debian installation and upgraded
that. The package installed is installed system-wide and the source
code is installed in /opt/rt4 .

The web is configured with the following configuration:

FastCgiServer /opt/rt4/sbin/rt-server.fcgi -processes 5 -idle-timeout 300

<VirtualHost *:80>
Servername
ServerAdmin webmaster@

    AddDefaultCharset UTF-8
    ScriptAlias / /opt/rt4/sbin/rt-server.fcgi/

    DocumentRoot "/opt/rt4/share/html"
    <Location />
        Order allow,deny
        Allow from all

        Options +ExecCGI
        AddHandler fastcgi-script fcgi
    </Location>

    CustomLog /var/log/apache2/<fqdn>_access.log combined
    ErrorLog /var/log/apache2/<fqdn>_error.log

Here’s the /opt/rt4/etc/RT_SiteConfig.pm:

Set( $Timezone, ‘Europe/Oslo’);
Set( $rtname, ‘’);
Set( $Organization, ‘’);
Set( $WebDomain, ‘’);
Set( $CorrespondAddress, ‘’);
Set( $CommentAddress, ‘’);

Set( $WebPath, “”);
Set( $WebBaseURL, “http://”);

Set ($MessageBoxRichText, 1);

Set( $PreferRichText, true);
Set( $MaxInlineBody, 0);

Set( $DatabaseName, “rtdb”);
Set( $DatabaseUser, “rt”);
Set( $DatabasePassword, “”);
Set( $DatabaseHost, “localhost”);

Set( %GnuPG,
Enable => 1,
);

You must install Plugins on your own, this is only an example

of the correct syntax to use when activating them.

Plugin( “RT::Extension::QuickDelete” );

Plugin( “RT::Extension::CommandByMail” );

Set(@Plugins, qw(RT::Extension::AdminConditionsAndActions));

Regarding the rest of the environment this is then running on Debian
Squeeze 6.0.7 in a virtual environment.

Do you need anything else?

  • Marius

I have exactly the same problem. I’ve investigated the loading of the page with the
WYSIWYG-editor and got the following results:

[1]http://s22.postimg.org/wqo1j42r5/wysiwyg.png

Maybe this will help debugging this further?

After the initial load the future loads of that js will be cached and therefore much slower.
And after the cache expiry (typically the next workday) you have to wait for another 30
seconds to get the WYSIWYG editor back up again.
While this confirms that something is taking a long time to load, the
consistent 15 seconds on each request is quite odd, especially since
larger files take mere milliseconds to download.

Are you using JSMin? How is your RT configured, etc, etc.
If you can replicate these timings on issues.bestpractical.com it
would be interesting.
I have the following output from Chromium’s network headers when loading
ckeditor.js. When refreshing the page (F5) this timeout of 15 seconds
occurs. You see the Keep-Alive is set to timeout=15, what does that mean?

  1. Request URL:
    http://RT-site/static/RichText/ckeditor.js
  2. Request Method:
    GET
  3. Status Code:
    200 OK
  4. Request Headersview source
    1.
    Accept:
    /
    2.
    Accept-Encoding:
    gzip,deflate,sdch
    3.
    Accept-Language:
    en-US,en;q=0.8
    4.
    Cache-Control:
    max-age=0
    5.
    Connection:
    keep-alive
    6.
    Host:
    RT-site
    7.
    If-Modified-Since:
    Wed, 27 Nov 2013 09:14:28 GMT
    8.
    Referer:
    http://RT-site/
    9.
    User-Agent:
    Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like
    Gecko) Chrome/28.0.1500.95 Safari/537.36
  5. Response Headersview source
    1.
    Connection:
    Keep-Alive
    2.
    Content-Encoding:
    gzip
    3.
    Content-Length:
    452578
    4.
    Content-Type:
    application/javascript
    5.
    Date:
    Thu, 09 Jan 2014 09:20:09 GMT
    6.
    Keep-Alive:
    timeout=15, max=100
    7.
    Last-Modified:
    Wed, 27 Nov 2013 09:14:28 GMT
    8.
    Server:
    Apache/2.2.16 (Debian)
    9.
    Vary:
    Accept-Encoding

Any ideas? This is very annoying as it slows down RT.

  • Marius