On 01/29/2012 10:47 PM, Reindl Harald wrote:
> Interesting - Pauls Reply was blocked by Barracuda-Spamfirewall
> Seems this was only a temporary problem Zeit: 2012-01-27 10:05:06
> Aktion: Geblockt Begründung: Barracuda Reputation (213.214.111.4)
> Absender-IP-Adresse: dbmail01.icns.fastxs.net[213.214.111.4]
'Reputation' based on what? RBLs are a completely failed concept imo.
>> This will break IMAP body searches (who uses those??)
>
> hmm - i do :-)
What client?
>
>> As to the connection-pooling: ymmv. PostgreSQL has a different
>> sweetspot than MySQL. It depends on the concurrency levels you
>> experience
>
> 2.2 has currently around 250 mysql-connections a smaller count
> would free per-connection-buffers for innodb_buffer-pool
>
> what i am missing are the parameters for connection pooling the
> "dbmail.conf" from the last RC-sources looks like the dbmail 2.2.x
It's there alright:
#
# Number of database connections per threaded daemon
# This also determines the size of the worker threadpool
#
#max_db_connections = 10
>
> AFAIR pooling is only for imap currently and nor for POP3 or am i
> missing something here?
You are.
All 3.0 programs use libzdb for the database handling. This implies a
connection pool.
All 3.0 network daemons use a non-blocking async network architecture
for communications with clients using libevent.
However: database queries are blocking! So when I first did the
libevent transition I quickly ran into throughput issues caused by
longer-running database queries. When everything is handled by one
single thread this led to pretty poor performance when more than say
10 imap clients were connected.
This was solved by making the IMAP code - and only the IMAP code -
multi-threaded. Now for IMAP a pool of worker threads is created; one
thread for each database connection in the database pool. These
workers pull their workload of an async message queue filled by the
main thread which deals with all the network IO. The workers do their
thing and pass the message back to the main thread via a separate
message queue.
pop3d, lmtpd and timsieved however just run one single main thread.
pop3 queries are pretty fast, lmtp is asynchronous be nature (no
humans waiting), and timsieve is run only infrequently, with low
volumes and fast queries.
Admittedly if you run very heavy POP3 traffic you will have to make
provisions if real-world testing proves throughput to be too low - for
example startup multiple pop3d processes on different ports and run a
load-balancer in front. If there is serious interest in better
throughput for pop3 I may reconsider but it just didn't seem to
warrant the investment at this time.
--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin
* Premium Hosting Services and Web Application Consultancy *
www.nfg.nl/[email protected]/+31.85.877.99.97
________________________________________________________________
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
