To be improved @ ask.fp.o
Grade F on Configure entity tags (ETags)
There are 26 components with misconfigured ETags
upstream askbot is good on this.
Grade A on Configure entity tags (ETags)
Other than this, everything else looks like can be fixed at upstream.
One major difference against upstream is ask.fpo is running on https.
The wait time on the initial connect itself is about 0.5 sec. As much as I
see, NY is served from a VM at UNC vs a linode for the askbot. So I guess
we will have to do more tweaking on our end even just to be at par with the
upstream if not better.
On Mon, Sep 9, 2013 at 5:32 AM, Ankur Sinha <sanjay.ankur(a)gmail.com> wrote:
Hi Anshu, Kevin,
On Sun, 2013-09-08 at 10:07 -0600, Kevin Fenzi wrote:
> On Sun, 8 Sep 2013 14:19:20 +0530
> Anshu Prateek <anshprat(a)gmail.com> wrote:
> > The generic yslow grades suggest couple of improvements:
> > Grade F on Add Expires headers
> > There are 55 static components without a far-future expiration date.
> > Grade F on Configure entity tags (ETags) There are 27 components with
> > misconfigured ETags
> > Grade E on Use cookie-free domainsThere are 9 components that are not
> > cookie-free
> > And some more.
> > All of these for https://ask.fedoraproject.org/questions/
Can you tell if these are issues limited to our deployment, or if they
are things upstream needs to correct, in which case we can go ahead and
> Yeah, askbot is using our haproxy/varnish setup as well as memcached, so
> if upstream can tweak things to be more caching friendly that would help
> for sure.
I compared the pingdom tests for our askbot instance, against the one
that upstream has deployed:
Upstream's deployment takes 1.07 seconds, while ours takes 3.07. Would
this imply that we can at least tweak our deployment to perform as quick
(Upstream's comment posting etc. doesn't lag at all either. The comment
is posted as soon as one clicks "post".)
> Actually in this case you might want to look at the django level one?
> MIDDLEWARE_CLASSES = (
> There may also be some other caching stuff there we should or shouldn't
> enable... not sure anyone has fully investigated all those.
I'll look into these, see if there's one we can use.
Join Fedora! Come talk to us!
infrastructure mailing list