On Sat, Sep 04, 2010 at 03:02:00AM -0500, Stan Hoeppner wrote:
> If we're using delays=a/b/c/d for troubleshooting that's fine. But if
> we're expecting to be tuning a server for performance based on log
> metric data we need time data for our rejected messages as well.
The purpose of the a/b/c/d logging is to allow you to isolate the origin
of message processing latency for mail that enters your queue.
If you are running a reasonably recent Postfix release, and
"stress-dependent" behaviour is never or rarely triggered (this
is logged), then your input is fast enough.
You cna monitor the average number of established connections to your
server, and compare that to the maximum process limit for the "smtp inet"
(i.e. smtpd) service. So long as the connection load stays below the
maximum configured load, you are fine. If not, look into "postscreen"
in the 2.8 snapshot.
> The main reason I ask is that my filters are constantly becoming more
> complex and the hardware remains the same. I'd like to be able to see
> how much additional load I'm adding to my system with the constant
> addition of new filters.
What do you mean by "filters"? Connection concurrency is proportional
to the connection lifetime and the connection rate. You can measure the
impact of increased connection lifetime by observing the average number
of concurrent connections to your server. Keep an eye on the CPU load
and the disk I/O utilization.
> Any chance this is on the agenda? Or does this type of log data already
> exist, and I'm simply too blind to find it?
Fine-grained logging of time spent in the various input stages has
not proved necessary, so far.
--
Viktor.
