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=<[email protected]>,
> 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=<[email protected]>, 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