In case it helps others, I’ve just written a long blog post about what I
did to significantly speed up our instance of RT 3.6:
http://feeding.cloud.geek.nz/2010/07/improving-performance-of-request.html
Quick summary:
Our RT is now really snappy!
Cheers,
Francois
signature.asc (836 Bytes)
Would the same speed ups apply for 3.8.8?-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Francois Marier
Sent: Friday, 9 July 2010 2:39 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] RT performance enhancements
In case it helps others, I’ve just written a long blog post about what I did to significantly speed up our instance of RT 3.6:
http://feeding.cloud.geek.nz/2010/07/improving-performance-of-request.html
Quick summary:
Our RT is now really snappy!
Cheers,
Francois
Would the same speed ups apply for 3.8.8?
I haven’t tried it on RT 3.8, but I’m pretty sure you’d see similar
effects since the non-optimised graphs I see from a RT 3.8 instance are
very much like the 3.6 ones I had.
Cheers,
Francois
signature.asc (836 Bytes)
Cheers, will give it a shot, and let the list know when I’ve done that :)-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Francois Marier
Sent: Friday, 9 July 2010 2:54 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] RT performance enhancements
On Fri, 2010-07-09 at 14:51 +1000, Rajesh Singh wrote:
Would the same speed ups apply for 3.8.8?
I haven’t tried it on RT 3.8, but I’m pretty sure you’d see similar effects since the non-optimised graphs I see from a RT 3.8 instance are very much like the 3.6 ones I had.
Cheers,
Francois
Would the same speed ups apply for 3.8.8?
I haven’t tried it on RT 3.8, but I’m pretty sure you’d see similar
effects since the non-optimised graphs I see from a RT 3.8 instance are
very much like the 3.6 ones I had.
That’s pretty surprising to me, as we’re squishing CSS and marking
static objects as static and cacheable and are using -moz and
-webkit-border-radius for the corner rounding. I’d be curious to see
what you’re seeing.
Would the same speed ups apply for 3.8.8?
I haven’t tried it on RT 3.8, but I’m pretty sure you’d see similar
effects since the non-optimised graphs I see from a RT 3.8 instance are
very much like the 3.6 ones I had.That’s pretty surprising to me, as we’re squishing CSS and marking
static objects as static and cacheable and are using -moz and
-webkit-border-radius for the corner rounding. I’d be curious to see
what you’re seeing.
Test was made on 3.6 which uses images for round corners, css squishing
was here, but not for js. In 3.8 there were also some fixes around
caching of static files.
So this test should be run on 3.8.8, and it should not show such
problems 
I haven’t tried it on RT 3.8, but I’m pretty sure you’d see similar
effects
since the non-optimised graphs I see from a RT 3.8 instance are very much
like the 3.6 ones I had.That’s pretty surprising to me, as we’re squishing CSS and marking static
objects as static and cacheable and are using -moz and
-webkit-border-radius
for the corner rounding. I’d be curious to see what you’re seeing.
On the RT 3.8.5 instance I have access to, I’m seeing this:
a Firebug screenshot is attached.
Should I be seeing something different? Is it different in 3.8.8?
(I’ll have to check how this instance is configured, but I think it’s
using the default Apache mod_perl config file that ships with RT.)
Cheers,
Francois
I haven’t tried it on RT 3.8, but I’m pretty sure you’d see similar
effects
since the non-optimised graphs I see from a RT 3.8 instance are very much
like the 3.6 ones I had.That’s pretty surprising to me, as we’re squishing CSS and marking static
objects as static and cacheable and are using -moz and
-webkit-border-radius
for the corner rounding. I’d be curious to see what you’re seeing.On the RT 3.8.5 instance I have access to, I’m seeing this:
- no rounded corner images (unlike 3.6)
- images served statically
- css files squished
- javascript not squished
- javascript and css served by mod_perl (my guess)
We’ve definitely improved caching behaviour in the past year or so
(3.8.5 was early fall 2009). The firebug profile of the first request of
index.html isn’t so interesting for me. What do you see on subsequent
requests? How does it compare with what you see on
http://issues.bestpractical.com? (login as guest / guest)
The firebug profile of the first request of index.html isn’t
so interesting for me. What do you see on subsequent requests?
The RT 3.8.5 firebug screenshot I posted earlier was the best one I got
after reloading the page 10-20 times, so it’s not the first request. I
would expect it to reflect the maximum number of cache hits.
How does it compare with what you see on
http://issues.bestpractical.com? (login as guest / guest)
Well, that one is a lot slower for me. (Though, that’s probably because
it’s a lot busier and that I’m connecting to it from New Zealand.)
In terms of caching, not even the images are cached by my browser
(something that the default 3.8.5 config does do). I have attached a
Firebug profile for that site (after reloading the first page a few
times).
Cheers,
Francois
How does it compare with what you see on
http://issues.bestpractical.com? (login as guest / guest)In terms of caching, not even the images are cached by my browser
(something that the default 3.8.5 config does do). I have attached a
Firebug profile for that site (after reloading the first page a few
times).
How are you hitting reload? The response you’re getting sure looks
like you’re doing a browsercache-busting shift-reload.
Can you show me the headers you’re getting from one of the requests
coming off of issues.bestpractical.com?
I’m currently traveling in france and seeing something far less awful
for caching behaviour out of issues.bestpractical.com.
How are you hitting reload? The response you’re getting sure looks
like you’re doing a browsercache-busting shift-reload.
I just click the regular reload (hitting r in vimperator) but with
Firebug’s network window open. I think you might be on to something
though, because Firebug probably needs to do a full reload in order to get
proper stats on each of the files.
Can you show me the headers you’re getting from one of the requests
coming off of issues.bestpractical.com?
I’ve attached the headers for my RT 3.8.5 instance as well as your
issues.bestpractical.com. It looks like the reason why I’m getting these
“304 Not modified” on the 3.8.5 instance is that Apache adds ETags to the
responses.
But regardless of whether or not ETags are present, in a normal setting,
the browser will probably not re-request these files (due to the caching
headers set by RT) and so all you’ll be getting once you’re past the first
screen is the HTML of each page.
Cheers,
Francois
rt385_headers.txt (1023 Bytes)
rt388_headers.txt (952 Bytes)
How are you hitting reload? The response you’re getting sure looks
like you’re doing a browsercache-busting shift-reload.I just click the regular reload (hitting r in vimperator) but with
Firebug’s network window open. I think you might be on to something
though, because Firebug probably needs to do a full reload in order to get
proper stats on each of the files.
That behaviour is different than I get by, say, browsing to
Login twice in a row, which more
accurately models what real users are doing. When I do that, firebug
does not reload any of those resources.
I appreciate the work you’ve done to look at RT’s web peformance and you’re right that we could improve first-page load further by squishing our javascript, but I don’t think that your profiling is really giving you an accurate picture of how RT 3.8 does things.
Best,
-Jesse