[squid-users] peek and splice content inspection question

[Alex Rousskov]

On 08/13/2015 10:31 PM, Amos Jeffries wrote:
> AFAICS it
> is the backend AV library only scanning disk objects that causes the
> whole issue. Otherwise the eCAP could be much, much faster.

The situation is more nuanced: eCAP supports asynchronous adapters. It
is possible to write a ClamAV adapter that writes messages to disk and
analyses them without blocking Squid. Doing so should eliminate most
overheads between Squid and ClamAV.

Factory ClamAV adapter can run in asynchronous mode, but threads are
only used for _analysis_ of written files. We have not optimized the
file writing part (yet?). Hopefully, using a RAM-based file system can
mitigate a large part of that performance damage (as well as address
some of the security concerns related to disk storage?).

A bigger performance problem, AFAICT, is that ClamAV does not support
incremental analysis. It waits for the entire file to be downloaded
first. This breaks the message delivery pipeline and increases
user-perceived response time. This problem cannot be solved outside the
ClamAV library.


Cheers,

Alex.