kgc at sonic
Aug 6, 2003, 3:30 PM
Post #6 of 6
On Thu, Aug 07, 2003 at 12:02:00AM +0000, Julien Benoist wrote:
> On Wed, 6 Aug 2003, Tomasz Kojm wrote:
> > > >
> > > > You should save all data to a temporary file and run cl_scandesc on it.
> > >
> > > Agreed, but i actually wanted to avoid it for performance reasons.
> > Oh, I think it's a missed idea - what about really big attachments ?
> Our system has a maximum attachment size, but i believe this idea is not
> that good :D
> > > ok for the rarfail.rar file, but cl_perror() also returned some "ZIP
> > > module failure" while scanning some other files (it did work with ex1.c).
> > > Throught, in the above code, replacing this fd to pipe by a fd to file
> > > worked pretty well.
> > descriptor has to be seek()able
> i see, and seek()ability of pipes are OS related ?
> Anyway, the performance issue i'm talking about is the following: some
> postifx will forward mails to some filterservers via a tcp socket, these
> servers will perform antispam & antivirus checks, and return the mail with
> enriched headers. I'm just afraid that writing all of these stuff to the
> disk would be load intensive, as we have a huge ammount of incoming mails
> per second.
> But I'll go this way and post to the list to tell you about how it runs.
In similar situations here we try to use tmpfs, /dev/shm, etc, for temp
file storage. You'll need to have enough ram, but you'll keep the tempfiles
off of your disk subsystem which will probably be the bottleneck.
Kelsey Cummings - kgc [at] sonic sonic.net, inc.
System Administrator 2260 Apollo Way
707.522.1000 (Voice) Santa Rosa, CA 95407
707.547.2199 (Fax) http://www.sonic.net/
Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896