[Rspamd-Users] Scan time

G.W. Haywood rspamd at jubileegroup.co.uk
Wed Jun 29 17:18:17 UTC 2022


Hi there,

On Wed, 29 Jun 2022, Michael Grundmann via Users wrote:

> Am 29.06.22 um 17:28 schrieb G.W. Haywood via Users:
>
> am I stupid in this threat?

Are you asking me?  This thread notwithstanding, I doubt you're stupid.

> So as I understand:
> 1) Srikrishnan has a DNS Problem - so the scans go up to 4 seconds

I don't think we've seen enough information to know that there's a DNS
problem, but there might be.  We've seen that the OP has scanned a
single message and found that it took at least twice as long as the
average of the different scans of different messages which are done by
his production system.  I think he's worried that if he scans all his
mail in the same way that he scanned the test message then his systems
would not be able to cope with the load.  But he has not actually said
that, and he hasn't produced any evidence for such a claim.

What he has said is that a scan time of 4.5 seconds is a problem.  It
is not clear to me why he thinks that.  Using a completely different
scanner (but which is a very heavy user of DNS resources) I often see
scan times three or four times as long as that.  It isn't a problem
because the systems can handle dozens of mail messages concurrently.
Most mail systems can do that; some can do a lot more.  We do not yet
know how the OP's 4.5 seconds breaks down into CPU, I/O, waiting for
packets on the wire...

> 2) the second question was, can he build his own fuzzy server
>
> Is that right?

That seems like a reasonable interpretation.  My concern is that if he
does that, he might not actually improve his situation.  His scanning
at the moment takes up to two seconds per message but his throughput
is apparently 600,000 messages per day - even though he doesn't have a
time machine.  So it appears that his systems manage well enough now.
If, based on the evidence that I've seen so far in this thread,
someone asked me to spend my own money on more equipment I'd tell him
to go away and come back with more information to justify the request.

-- 

73,
Ged.


More information about the Users mailing list