Opened 13 years ago

Last modified 13 years ago

#266 closed defect (FIXED)

Improve cache friendliness of static content

Reported by: Elrond Owned by: Christopher Allan Webber
Priority: minor Milestone: 0.1.0
Component: programming Keywords:
Cc: Parent Tickets:


If not serving the (semi-)static content (css etc and the media
items) through a dedicated webserver but using paste#static the
caching is bad.

It could easily be argued, that on a real deployment, these tings
should be served by a dedicated webserver. But still, the paste
based setups should give reasonable caching.

There are two items to consider:

1. mediagoblin/mgoblin\_static/ (CSS, ...)

Only layout/etc developers will change this and those will likely
use "reload" on their browsers anyway. Everybody else will only
change this when updating their install. So even thinking about
people updating and wanting a fresh look soon, at least an hour
would be good. I'd rather suggest a day.

2. media content (public\_store)

media items aren't **modified** currently. They get written once
and stay there as written. Creating a new media entry, creates a
new object id, etc. I'd say a week is good.

Change History (8)

comment:1 by Elrond, 13 years ago

So how to implement this? Simple.

And thinking again about it, I'd suggest a day for the css/etc


    --- a/paste.ini
    +++ b/paste.ini
    @@ -19,10 +19,12 @@ config = %(here)s/mediagoblin.ini
     use = egg:Paste#static
     document_root = %(here)s/user_dev/media/public/
    +cache_max_age = 604800
     use = egg:Paste#static
     document_root = %(here)s/mediagoblin/static/
    +cache_max_age = 86400
     use = egg:Beaker#beaker_session

comment:2 by Elrond, 13 years ago

Component: Programming
I'll happily push a branch, if someone wants me to.

comment:3 by Christopher Allan Webber, 13 years ago

Hm. I have a pretty significant concern with this, and that's
memory bloat. Imagine you're serving a .webm file... wouldn't that
bloat your memory keeping that cached really fast? What if you're
serving 10? ;)

I do think it's best that we serve this stuff through apache and
etc... I do also agree that a lot of people won't configure things
right from the get-go, and so we should provide sane defaults.

How about a compromise... we keep commented-out versions of those
options in the file, with a comment above them explaining
"uncomment these to enable simple python-side caching"?

comment:4 by Elrond, 13 years ago

These options do not affect memory on the server(!) in any way.
They affect cache on the client.
They tell the client: The content it just received will not change
in the next N seconds. Nothing more, nothing less. Client decides
how to use this info. Clients usually cache this stuff and decide
not to ask the server over and over again for the same file. Good.
Saves network bandwidth.

Over simplifications used above: 1. The **config** will take a few
bytes of ram on the server. 2. I'd guess, proxy servers are allowed
to cache too.

comment:5 by Elrond, 13 years ago

Milestone: 0.1.0
Owner: set to Elvenlord Elrond
Talked to chris. We'll do like I suggested.
I'll push a branch (assigned to me for that reason).

comment:6 by Elrond, 13 years ago

Owner: changed from Elvenlord Elrond to Christopher Webber
Status: NewFeedback
New branch: misc/f602\_client\_cache\_improvement

comment:7 by Christopher Allan Webber, 13 years ago

Status: FeedbackClosed

comment:8 by Will Kahn-Greene, 12 years ago

The original url for this bug was .

Note: See TracTickets for help on using tickets.