docs/frontend.rst

   1 Frontend & Backend
   2 ==================
   3 The postgresql.org website is designed to run in a frontend/backend
   4 scenario. This is to achieve both load distribution and redundancy for
   5 the case when the main webserver (known as wwwmaster) goes offline or
   6 becomes loaded.
   7
   8 Previous versions of the website used static files on the frontend,
   9 that were spidered at regular intervals and then push-rsynced out to
  10 the frontends. This made the frontends entirely independent of the
  11 backends, and as such very "available". Unfortunately it made a lot of
  12 coding difficult, and had very bad performance (a re-spidering
  13 including documentation and ftp would take more than 6 hours on a fast
  14 machine).
  15
  16 This generation of the website will instead rely on a varnish web
  17 cache running on the frontend servers, configured to cache things for
  18 a long time. It will also run in what's known as "grace mode", which
  19 will have varnish keep serving the content from the cache even if it
  20 has expired in case the backend cannot be contacted.
  21
  22 All forms that require login will be processed directly by the master
  23 server, just like before. These will *always* be processed over SSL,
  24 and as such not sent through varnish at all. They will still be
  25 accessed using the domain www.postgresql.org, which will then simply
  26 proxy the SSL connection to the backend. For the initial deployment
  27 we'll just use HAProxy, but we may switch to a more feature-rich
  28 proxy server in the future - in which case it's important to maintain
  29 the encrypted channel between the frontend and the backend, since
  30 they are normally not in the same datacenter.
  31
  32 Requests that require *up to the second* content but do *not* require
  33 a login, such as a mirror selection, will be sent through the
  34 frontends (and served under the www.postgresql.org name) but without
  35 caching enabled. Note that in most cases, these should actually be
  36 cached for at least 5 or 10 seconds, to cut off any short term high
  37 load effects (aka the slashdot effect).
  38
  39 Normal requests are always cached. There is a default cache expiry
  40 that is set on all pages. There is a longer default policy set for
  41 images, because they are considered never to change. Any view in the
  42 django project can override this default, by specifying the
  43 "Cache-control: s-maxage=xxx" http header on the response. This is
  44 done by using the @cache() decorator on the view method. Caching
  45 should be kept lower for pages that have frequently updating data,
  46 such as the front page or the survey results page.
  47
  48 Any model can define a tuple or a function
  49 called *purge_urls* (if it's a function, it will be called and
  50 should return a tuple or a generator). Each entry is a regular
  51 expression, and this data will be automatically removed from the
  52 frontend caches whenever this object changes. The regular expression
  53 will always be prepended with ^, and should be rooted with /.
  54 It should be made as restrictive as possible (for example, don't
  55 purge "/" since that will remove everything from the cache completely).
  56 This makes it possible to have frontends react instantly to changes,
  57 while maintaining high cacheability.
  58
  59 Finally, there is a form on the admin web interface that lets the
  60 administrator manually purge pages from the caches. This may be
  61 necessary if changes have been made to static pages and/or site
  62 structure that otherwise wouldn't show up until the cache has
  63 expired.