Re: (tye)Re: Perl Performance Question

This is something I was thinking of. Hopefully, if the "processor" can't keep up with the "gatherer," it would be able to make up for lost time during non-peak times.

Comment on Re: (tye)Re: Perl Performance Question

Replies are listed 'Best First'.
Re: Re: (tye)Re: Perl Performance Question by IkomaAndy (Acolyte) on Jun 14, 2001 at 00:06 UTC
I implemented this "disk queue" system, and found it very slow, even using a memory-based /tmp filesystem (on Solaris 2.6). I could only process about 200 flows per second, as opposed to the ~1,000 per second that should be gathered. That's a pretty extreme backlog-- I don't know if I would even be able to consume it during offpeak times. I didn't really see a slowdown in gathering when the "processor" was running, though, something I wondered about when writing to disk.	[reply]

Replies are listed 'Best First'.

Re: Re: (tye)Re: Perl Performance Question
by IkomaAndy (Acolyte) on Jun 14, 2001 at 00:06 UTC

I implemented this "disk queue" system, and found it very slow, even using a memory-based /tmp filesystem (on Solaris 2.6). I could only process about 200 flows per second, as opposed to the ~1,000 per second that should be gathered. That's a pretty extreme backlog-- I don't know if I would even be able to consume it during offpeak times. I didn't really see a slowdown in gathering when the "processor" was running, though, something I wondered about when writing to disk.

[reply]