He's a Ghost, He's a God, He's a Man, He's a Guru (corvar) wrote in lj_dev,
He's a Ghost, He's a God, He's a Man, He's a Guru
corvar
lj_dev

  • Music:

Saving Server/Bandwidth Resources

Reading the entries in lj_maintenance and revjim's comment here in lj_dev, I started thinking about how well it would work to improve the cachability of livejournal.

Benefits would be reduced bandwidth, and possibly reduced queries the databases.

Current state of caching on Livejournal:

Cache-Control headers set to "private, proxy-revalidate", this means no decently compliant cacher will think about caching the information.

ETag headers are not set properly in all locations. talkpost.bml seems to set it correctly, but my user page does not. At least the ETag is not recognized by Cachability Query.


Possible changes:

If a valid ETag is being generated, i.e. one that is unique for the content on the page, everything is at least somewhat known before the page is spit out. This means that it would be possible to see if there were any friends only/private posts on the page before the headers are sent out. That would allow pages without friends/private posts to have a Cache-Control headers which doesn't include "private".

It would still be possible to cause cacher's to make sure the page is still up to date before spitting it at the end user, or to put some low value of required caching. The value set for required caching could vary between paid and free accounts to save more bandwidth/server resources.

If a valid ETag is being generated, it should be possible to generate a valid Last-Modified headers as well. Last-Modified seems to work better for some unknown reason.


Now I will admit I am not familiar with the codebase, so some of these changes could possibly cause more harm (DB Activity) than good, but I thought I would spew this forth and see if it made sense.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 16 comments