At 02:44 AM 7/28/01, Philip Mak wrote:
>On Sat, 28 Jul 2001, Adrian Ho wrote:
>
> > Why use a program delivery when you can use .qmail forward
> directives?
> > "man dot-qmail" for details, and create the necessary .qmail files
> > (probably .qmail-youralias in the same directory you put your
> domain's
> > .qmail-default).
>
>Well, there's over 10,000 e-mail addresses that would have to be
>forwarded. Wouldn't I have to create a .qmail-<name> file for everyone
>in
>the MySQL database (would there be a filesystem efficiency issue when
>I
>have 10,000 files in the directory?)
That depends on your filesystem. I've just learned of ReiserFS, isn't
this the kind of thing that it's good at?
>, and also keep these files synchronized with inserts, updates and
>deletes done to the MySQL database?
How often do you expect it to change, and what triggers the
change? Write a cron job that updates the .qmail files periodically
with the information in the database.
Better yet, update the .qmail file at the same time you update the
database.
>I figure that it's cleaner, programming-wise, to just lookup the MySQL
>database at the time a message is received rather than having to worry
>about synchronization. But this lookup script has increased the load
>average of the server above 10.
There is at least one mysql/qmail integration package floating around,
have you looked at any of those?
You're going to have a very hard time making this tiny and fast, which
is what it needs to be. For every message, you're firing up the perl
interpeter, connecting to the database, parsing a statement, executing,
and cleaning up the whole mess. All of these things are expensive.
You might be able to improve things be writing a daemon (in perl if
you'd like) that spins in the background and takes connections from the
various .qmail files. That will at least eliminate the
once-per-message startup, and you could probably get it to share
database handles.
That's a lot of work, and a lot of shit to break.
cheers,
Todd
