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. _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
