Michael,
(myself wrote:)
> [...] with a new subroutine
> clamav_clamd_internal() implementing the zINSTREAM, combined
> with batched parallel processing of parts as offered by
> the clamd's zIDSESSION / zEND commands.
>
> The following AV entry will invoke it:
>
> ['ClamAV-clamd-stream',
> \&ask_daemon, ["*", 'clamd:/var/run/clamav/clamd'],
> # \&ask_daemon, ["*", 'clamd:127.0.0.1:3310'],
> # \&ask_daemon, ["{}/../email.txt", 'clamd:/var/run/clamav/clamd'],
> qr/\bOK$/m, qr/\bFOUND$/m,
> qr/^.*?: (?!Infected Archive)(.*) FOUND$/m ],
>
> That timing is still a puzzle, it seems that clamd takes much
> longer to process a complete non-decode mail message than its
> decoded components
> (using a qr'^MAIL$' entry in the @keep_decoded_original_maps list).
>
> It should take about the same time as using a traditional
> CONTSCAN with a directory name sent to clamd, yet CONTSCAN seems
> to be much faster for complete mail messages, and about the same
> speed for decoded mail components - or so it appears to me.
It seems I solved the puzzle: whichever of the three AV scanners
(ClamAV-clamd-stream, ClamAV-clamd, ClamAV-clamdscan) is
invoked first, takes most of the elapsed time for processing.
The other two that follow are very fast (regardless of the order).
So it appears the clamd caches results of its recent scans.
Mark
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
Please visit http://www.ijs.si/software/amavisd/ regularly
For administrativa requests please send email to rainer at openantivirus dot
org
