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 >