Quoting Dennis Peterson <[EMAIL PROTECTED]>: >> No, it _IS_ subjective, and it depends on your available resources. And in >> my opinion, with my resources, it is tolerable. Your milage may vary. > > Sorry, no. For any particular machine you can measure the performance of > each clamav client and you will get distinctly different performance > figures.
Correct. I have a feeling you're trying to make a different point, or reply to a different posting, than I am though. If you want to say that clamscan in 0.90.* is slower than that in 0.88.* then you are correct. If you are trying to say that in general you will get faster performance from clamd+clamdscan than from clamscan on a highly loaded server, than you are correct. My reply is to those who say clamscan is too slow for use, or that clamscan should not be used in production, or that clamscan should never be used on a mail server, or that the developers are not doing their job by making clamscan faster now instead of in the next release. I feel those statements are false. I feel there are good reasons to run clamscan instead of another option, and I feel that one can indeed do so if they have sufficient resources and enough smarts. > Clamscan has a startup penalty not found in clamdscan, and Yes. To be fair though, clamscan has the same penality as clamd. But clamd starts less often (one would hope at least). > while the newest version of clamscan is faster at loading the db files, > it is not zero seconds. What is subjective is how one responds to the data. What is subjective is whether the software is feasible for use on a mail server in the various configurations. > In my case I pass file pointers to clamd from a continuously running > milter so there is no startup cost at all. Sure there is. You're just moving it from one program to another. > Short of compiling the Clamav > libraries straight into the milter as is done with clamav-milter, I > don't know of a faster way to scan incoming mail in real time while the > connection is still made with the client MTA. So? That has nothing to do with the point I was trying to make, which is that you _can_ run a fairly high volume mail server using clamscan (any version) if you have sufficient system resources, and are willing to tolerate slow delivery times (up to 4 minutes on my system, with clamscan on 0.90.3 for example). > If you are waiting until after the MTA has accepted the message but > before the handing it LDA to scan then performance is less important. Which is a perfectly reasonable thing to do... > Anyway, you're happy so I'm happy :). Okay! Happy Happy Happy! :) > dp > _______________________________________________ > Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net > http://lurker.clamav.net/list/clamav-users.html > -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
