On Sat, 4 Oct 2003 11:17:24 +0100 (BST) Philip Hazel <ph10@???> wrote:
> On Fri, 3 Oct 2003, Wakko Warner wrote:
> > If people feel so strongly about not doing this thinking it's a bad
> idea,
> > why does exim even support sql at all? Surely having users, aliases,
> etc
> > in sql is a performance hit as well (and according to some people
> should not
> > be done).
> Personally, I've never been very happy about it for optimum
> performance,[*]
> but some sites have low load and today's computers are so fast that it
> doesn't seem unreasonable for those who are not worried by performance
> issues.
i recently worked with a business that had some 6000 or so users described
in a PostgreSQL database, and a fairly significant inbound mail load.
at first it was a dog, but with some tuning, tweaking, and adjustments, we
got it running pretty well.
if you're going to do this stuff in large scale operations, you need to
recognize that database tuning is itself an art form. a good dba can make
these things fly [1]. there is a requirement for the devotion of resources
specifically to the database server itself. just running the db on the
same box that you're running exim on will pretty seriously restrict the
scalability of the design.
> [*] For myself, I'd always go for a two-stage scheme, for instance,
> extracting aliases from a database into a "live" cdb file for Exim to
> use.
i'd consider this a very reasonable approach, so long as the core data in
the SQL database isn't changing rapidly (most don't change that rapidly.)
richard
[1] i'm hardly a brilliant sql db guy, but i'm busy climing that learning
curve and things look different once you get up it a ways.
--
Richard Welty rwelty@???
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
