> LW> Dont forget the -m option. If you have more than about 5 children
> LW> running and don't have a huge email flow you might do well to cut
the
> LW> number of children down to the 3 to 10 range.
>
> What is considered "huge email flow" and what are appropriate values for
> connections and children?
I'd think 5 children should be good for a few thousand mail/hour at least,
given a decent box (>= 1GHz) to run SA. A home net like you describe would
probably run perfectly happily with 1 or 2 children at most. Anything above
that is likely to just be sitting there using resources. Of course, if you
have the resources to burn, then it probably isn't worth cutting the number
of children down.
Look at it this way: how long does it take a child to process a message, on
average (total time, not processor time)? Maybe a few seconds at most?
Let's say 5 seconds as an estimate. Then each child can process 3600/5 =
720 messages/hour. You are receiving 1K messages/day, which is 1000/24=42
messages/hour. A single child would then have 17 times the capacity you
need, and would be idle 94% of the time. Five children taken together will
be idle something like 99% of the time.
Of course these are steady-state estimates, and queuing theory says that
things can get nasty for a while in burst modes if you only have one or two
children. So having 5 children can result in keeping the throughput time
down in the area of 10-20 seconds total queuing+processing time per mail
when you get a sudden flood of 50 or 100 mails in a short period of time.
Still, more than 3 children is probably overkill under any situation for
your mail rate.
> Does this make sense? Should I (can I) reduce the numebr of sendmail
> children to better match spamd?
Sendmail I don't know beans about, so hopefully someone else will be able to
answer those questions. Or possibly you can answer them yourself, if you
just consider the mail process as a long queue with lumps in it, and
determine what the overall linear processing time for a mail item is. If
you know the single-item processing time, you can assume (for lack of better
measurement information) that you can get a throughput that will be
something like (single item rate * number of parallel processes * 0.8)
before things got to hell and the queue depths start to blow out the top.
Loren
