Diagnosing Ask Fedora sluggishness

[Anshu Prateek]

https://fedorahosted.org/fedora-infrastructure/ticket/4013#comment:2

Default setup - 21 requests, 657kb, 1.04 s,
http://tools.pingdom.com/fpt/#!/3R3vS/http://fedora.hackalyst.info/questions/

Optimized setup - 15 requestsm 253kb, 708 ms ,
http://tools.pingdom.com/fpt/#!/eNP7yA/http://fedora.hackalyst.info/questions/

Both from NYC

(This is the latest askbot 0.7.49 install)

Changes made :

Added another domain for static resources . This reduces queue blocking.
Enabled js/css cache and minimization in django, this reduces number of
resource calls and their sizes.
Enabled gzip in apache. gzip in django is very restrictive and doesn't
serve our purpose here.

Askbot / django changes are all in settings.py only.

To Do:

Figure out way to split js, css and images to various domains. This will
improve speed further by cutting down wait time by half.

regards
Anshu Prateek


On Mon, Sep 9, 2013 at 1:31 PM, Anshu Prateek <anshprat at gmail.com> wrote:

> 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 at 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 at 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
>> file bugs?
>>
>> >
>> > 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:
>>
>> http://tools.pingdom.com/fpt/#!/bFd18x/http://askbot.org/en/questions/
>>
>>
>> http://tools.pingdom.com/fpt/#!/dmLsqz/http://ask.fedoraproject.org/questions/
>>
>> 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
>> as upstream's?
>>
>> (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?
>> > modules/askbot/templates/settings.erb:
>> >
>> > MIDDLEWARE_CLASSES = (
>> >     #'django.middleware.gzip.GZipMiddleware',
>> >
>> > 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.
>>
>> --
>> Thanks,
>> Warm regards,
>> Ankur (FranciscoD)
>>
>> http://fedoraproject.org/wiki/User:Ankursinha
>>
>> Join Fedora! Come talk to us!
>> http://fedoraproject.org/wiki/Fedora_Join_SIG
>>
>>
>> _______________________________________________
>> infrastructure mailing list
>> infrastructure at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20130926/e0d58879/attachment-0001.html>