Am 28.01.2015 um 15:46 schrieb Axb:
On 01/28/2015 03:18 PM, Kevin A. McGrail wrote:
On 1/28/2015 9:04 AM, Reindl Harald wrote:
my main point is that i don't want the locking IO when nothing then
the self developed maintainance scripts for the bayes has a business
to write anything there - it should be only read and in the best case
from each spamc-forker only opened once in his lifetime for best
performance
A) I have a feeling using Redis will provide the fastest performance
either way...

afaik, Redis requires "bayes_auto_expire  1" but one can set a huge TTL
for "bayes_token_ttl" &  "bayes_seen_ttl"

Of course, Redis also cause I/O when it dumps to disk but in all the SA
noise....

I don't understand why Reindl is so scared of the Bayes file based I/O

i am scared about the read-only-fs warnings cluttering the logs where there is no business to write anything

Using modern hardware, the DB file type is slower than any I/O but
then...  Lets assume he's scared of speed coz he does scans during the
smtp sessions  AND he's using the default DB backend instead of the
faster SDBM (or Redis) :)

i avoid additional complexity and dependencies for damned good reasons and the last time i did not so in case of prosody (jabber server) and used sqlite instead plaintext defaults it took me a lot of wasted time after a distr-upgrade

but then, he'll supply the patch. BAZINGA!

what a hostile reaction to reports

* first:  it is a bug to write/lock when auto_expire / auto_learn is off
* second: i am not a perl developer
* third:  if you would be a smart upstream in case of a company admin
          asking for a change instead "write a patch" you could make
          a offer talking about money to include the change in the
          next upstream version - we sponsored changes and maintainance
          of projects like DBMail, Netatalk and others multiple times
          in the last years - just because instead pertly responses a
          friendly "i am not that much interested but i guess the amount
          of time will be xx hours for xx € per hour and so i am open"

point 3 is BTW the reason why DBMail 3.x still has the native autoreply feature - so you developers should consider acting somehow less hostile and more smart in context of user-requests and make even money with it

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to