In some email I received from Gianni Mariani <[EMAIL PROTECTED]> on Tue, 01 Jul 2003 22:25:11 -0700, wrote:
> 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. not true in PgSQL 7.3.3 works fine with > 64 conn, alter the value in PGDATA/postgresql.conf + alter the buffer size 2xMAX_CONN I dont see a point hardcoding something like this?:) > 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. wey, how exactly is dbmail scheme slow? and how exactly using transaction will make it faster, please elaborate? I suppose rewriting the queries might speed up things a little bit. it's quite possible to wrap some queries into transactions, but I cant see _this_ really good reason why this should be implemented at this point (safe model). lock <ids> start trans; insert_message(id,blahblah) && insert_messageblks(id,blahblah) commit; > b) dbmail could also use stored procedures in Postgresql. This would > eliminate a bunch of processing on the server. why? it will break portability with other servers like mysql. Also that means all the load to be pushed to the database server rather than the client (dbmail server). (MySQL have stored procedures in 4.0.x or?) cheers
