Closed Bug 735498 Opened 12 years ago Closed 12 years ago

Add django-cache-machine to cache the Videos page

Categories

(Websites :: Firefox Flicks, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: stephend, Assigned: osmose)

References

()

Details

(Keywords: perf)

The initial view and repeat view of the Videos page isn't cached:

http://www.webpagetest.org/result/120313_DC_3JRTT/

First view: 9.720s
Repeat view: 9.311s

So mkelly is looking into adding django-cache-machine to dev, so we can test.
Uh, 9 seconds? Unless we're committing some crimes there, even an uncached request shouldn't take so long...
Yeah, this isn't meant to actually fix the 9 second load time, but since our videos aren't cached at all right now it should help at least a bit.

I'll be talking with jd tomorrow about how to find the real cause of the slowness.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
So, just a few (non-scientific) datapoints (on the /recent page, at least):

Prod: http://www.webpagetest.org/result/120314_6M_3JT35/

First View
(5.871s)

Repeat View
(3.469s)

Trunk/dev: http://www.webpagetest.org/result/120314_DG_3JT3B/

First View
(9.908s)

Repeat View
(6.375s)

(We'd have to repeat this multiple times in order to have a decent baseline, I feel.)

There are multiple factors at play, here, one of which is the Zeus/Riverbed caching (or are we on Citrix Netscaler, now?), the other is--likely--memcached--if we're on the generic memcached cluster.  I don't know enough about our setup for this on either prod or trunk/-dev, so it feels inconclusive.  Also, prod is likely more "warmed up" in terms of traffic/hits.

Needless to say, this is proven technology (and, thus, safe), and manual testing doesn't bear any fallout.

We'll chase this up again tomorrow, especially with JD's help.
You need to log in before you can comment on or make changes to this bug.