Maria Arrea: > Hello > > I have Red Hat Enterprise Linux 5, postfix 2.3.3 and dovecot 2.0.9. Mails >- are delivered to dovecot by virtual_transport=dovecot and the mailbox_comma >-nd is /usr/libexec/dovecot/deliver. Everything works as expected. > > In dovecot I am testing enabling zlib compression to save some IOPs and d >-isk space. I use the software postal to generate mail load and send 30.000 m >-essages of 2 megabytes in 1 hour, always the same test, with compression ena >-bled & disabled. > > My first question is about logs. Without compression in dovecot I got log >- lines like this: > > /Feb 4 14:10:13 buzon postfix/pipe[4018]: 4EA77C7775: to=<cor...@us.es>, > relay=dovecot, delay=1.6, delays=1.3/0.17/0/0.12, dsn=2.0.0, status=sent > (delivered via dovecot service)/ > > With compression enabled: > > Feb 3 17:48:25 buzon postfix/pipe[8263]: 2169CC7758: > to=<javierdemig...@us.es>, relay=dovecot, delay= *13*, delays= > *0.83/11/0/1.2*, dsn=2.0.0, status=sent (delivered via dovecot service)
A quick test in my FreeBSD laptop shows that it takes ~0.05 seconds of CPU time to compress 10MB of text with the gzip command (the numbers vary from 0.03s to 0.07s, depending on content). while : do cat largefile done | dd bs=1024k count=10 | /usr/bin/time gzip >/dev/null Based on this I'd expect ~0.01 seconds of additional delay for Dovecot compressing your 2MB messages, not the 1.1 seconds that you report. And my numbers are for the worst case where Dovecot forks off a gzip process, which I am sure it doesn't. My suspicion is that either you are running Postfix + Dovecot on a 100MHz CPU, or you are not doing a proper measurement, What are the AVERAGE delay values? What is the AVERAGE CPU load? How much swap space are you using? Wietse