On Tue, Jun 09, 2009 at 03:12:36PM +1000, Damien Miller wrote:
> On Mon, 8 Jun 2009, Christiano Farina Haesbaert wrote:
> > Another feature I was thinking would be to dump the output in one file
> > per host. What do you guys think ? Besides correcting fd limit, udp
> > support, any other ideas ?
On Mon, 8 Jun 2009, Christiano Farina Haesbaert wrote:
> Hmm, I didn't know we had a soft limit, I thought you had to recompile
> the kernel and tune max files, I agree, I'll add support for expanding
> the limit. Is there any sane limit ? Or I can push as far as it goes ?
Does your diff prealloc
On Mon, Jun 08, 2009 at 06:14:31PM +0200, Reyk Floeter wrote:
> hi,
>
> the idea sounds ok, but why just 128? tcpbench is for benchmarking
> and testing and it should be possible to run more concurrent
> connections.
>
> it could call getrlimit() to get the actual RLIMIT_NOFILE value which
> is
hi,
the idea sounds ok, but why just 128? tcpbench is for benchmarking
and testing and it should be possible to run more concurrent
connections.
it could call getrlimit() to get the actual RLIMIT_NOFILE value which
is 128 by default but can be much higher. another variant is the way
spamd/spamd
Hi,
The following patch makes tcpbench(1) non-forking and non-blocking,
I've changed the output to show the file descriptor instead of the
pid.
The server will no longer die due to excessive forking as it's all
wraped in a single process, we are limited however to 128 fds.
There is an error when
