Re: Caching Websites

scott.marlowe <scott.marlowe@ihs.com>

From: "scott.marlowe" <scott.marlowe@ihs.com>
To: Ericson Smith <eric@did-it.com>
Cc: Doug McNaught <doug@mcnaught.org>, Adam Kessel <adam@bostoncoop.net>, Postgresql General <pgsql-general@postgresql.org>
Date: 2003-05-12T17:27:57Z
Lists: pgsql-general
And if you're looking at performance caching, try SQUID.  It's complex to 
setup for most stuff, but as a simple single site http accelerator, it's 
pretty fast, and not nearly as hard to setup as when it is using a 
redirector (i.e. multi-backend / multi-frontend setup).

On 12 May 2003, Ericson Smith wrote:

> Maybe a little out of the loop... but if you're caching website stuff
> (html?, xml?), then it might be best not to use the Database. If your DB
> goes down... your content site goes down too.
> 
> I remember a project a little while back where we actually used plain
> ol, DBM files to cache the content. It was tens of times faster than the
> database, and would stay up no matter what.
> 
> I see what your're saying about the LO's but IMHO, the DB is not the
> best place for cached content.
> 
> - Ericson Smith
> eric@did-it.com
> 
> On Mon, 2003-05-12 at 12:04, scott.marlowe wrote:
> > On 12 May 2003, Doug McNaught wrote:
> > 
> > > "scott.marlowe" <scott.marlowe@ihs.com> writes:
> > > 
> > > > The advantage to storing them in bytea or text with base64 is that 
> > > > pg_dump backs up your whole database.
> > > 
> > > It does with LOs too; you just have to use the -o option and either
> > > the 'custom' or 'tar' format rather than straight SQL.
> > 
> > Cool.  I could of sworn that you had to back them up seperately.  Was that 
> > the case at one time?
> > 
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> > 
> > http://archives.postgresql.org
>