Christian G. Warden wrote:
On Tue, Jul 01, 2003 at 11:12:27AM -0500, Jeff Brenton wrote:
Hello Nunno,
NL> 1) IMAP : don't fork. With 6 process of dbmail i can serve 6 imap server.
NL> the 7'th user can't use imap server ????
If you've configured for 6 processes, that's how many you'll get, and
each process can handle one user. If you need 40 simultaneous users,
you need to configure for 40 IMAP processes.
Does anyone have plans to implement apache style process spawning as
needed?
Well, there's more to it. Postgresql also has a compiled in limit of
the maximum number of servers. If you want more than (64 by default)
postgresql connections, you'll need to build a new postgresql.
I think the right model is to have a single process server. In my last
job we created a streaming server that was a single process handling
1000 clients at 256kbit streams and hardly breaking a sweat on a 1.2Ghz
AMD dual. Everything is asynchronous. I'd reccomend this model with
database connection cacheing and you could probably survive with fewer
that 20 connections to the database and have thousands of clients
"connected". Using the new esyspoll stuff it's possible that to support
10,000*n of connections. This is the *Right*(TM) was to do this.
Heck, while I'm at it, I may as well rant on. Here are some more
possible improvements.
a) dbmail could use transactions (BEGIN/COMMIT blocks) and it would be
faster on Postgresql because the constraints need only be checked at the
commit.
b) dbmail could also use stored procedures in Postgresql. This would
eliminate a bunch of processing on the server.
c) I go both ways on the contents of the message being in the database.
No question that it is faster to send a file to a socket (using
sendfile) than it is to read the data from the database. So, handling
the message contents differently (placing it in a file) could easily
improve performance, not to mention the issues with encoding of the
database causing all kinds of issues. At the minimum, recent versions
of Postgresql also do large objects so theoretically you could store
messages in a single record.
The last one ... C++, 'nuff said.
G
