Re: Advice Required - for avoiding conflict betwen qmail-smtpd, rblsmtpd loaded as shared objects in tcpserver

Hi Charles.

I do agree with you on testing performance is important, but there are also other things to consider.
This information is just intended to be informal (things to consider).

On Sun, 2 Apr 2017 09:17:16 -0600, Charles Cazabon wrote:
> I'm afraid you're fooling yourself.  Any control files that are opened and
> read regularly - i.e. if you're getting at least a few SMTP 
> connections every minute - will be satisfied from the cache.

On most linux systems it might, but these days things are different.
You can run qmail under Linux or UNIX, but you might use a system, which does not have much memory to run your qmail.
If that's the case, the file cache might not be very efficient (or it might be disabled).

If you're developing on a system which has all the great features, performance testing might not show the right results in cases where "low-end" systems are used.

If memory is no longer duplicated to a new buffer on each read (from the cache), then it will certainly be a performance boost:
 * more memory will be available.
 * less time will be spent looking for a free block of memory.

Also, the PowerPC based Macs have some serious problems with locks, mutexes, spinlocks, etc; it may wait forever (I've seen up to 2 minutes) until it can access files (Yes, that's a flaw/bug/error in the system, but it will never be corrected along with thousands of other bugs, since Apple do not support old systems anymore).

I've been thinking about making an qmail-embedded, which use LWIP and no POSIX/Linux/UNIX calls (eg. stripping the operating system away completely); I might not have time for this, though. If I do that, it might be best to base it on s/qmail, as s/qmail much more up-to-date than the good ol' qmail. ;)

Some of these cases might apply to Manvendra's system, some might not.


Love
Jens