are you sure you aren't running out of mbufs ? netstat -m should tell you. Additionally, note that the 250ms of delay are probably way too much for your config (you are adding 250ms each way, which makes a 500ms RTT, not accounting for transmission times -- i think normal values here are more like 150-200ms rtt), and possibly irrelevant given how large your queues are -- a full-size packet is 12000 bits or 200ms, you can have up to 20 queued... cheers luigi On Mon, Apr 26, 2004 at 11:58:21PM +0200, Ivan Voras wrote: > I'm trying to see how a web server performes when "attacked" by many low > bandwith connections, and my idea is to use dummynet to simulate such > conditions from a single client computer on the same (100Mbps) LAN. I've > created a pipe: > > ipfw pipe 1 config bw 56Kbit/s delay 250 queue 20 buckets 1024 mask all > > My rules are: > > ipfw pipe 1 tcp from me to webserver dst-port 80 > ipfw pipe 1 tcp from webserver 80 to me > > When I start the benchmark program (siege) with relatively low > concurrency (50 clients), everything works as expected, but after > increasing to 100+ simultaneous requests, I start getting huge amounts > of "read error: Connection reset by peer" and "broken pipe" messages. > During that time the load on the web server is low (plenty of idle time > and memory). > > Without traffic shaping, the server handles 250-300 concurrent requests > without problems in the same setup. > > I've tried changing the queue and bucket size (and adding 'noerror'), > with no results. Eliminating latency (delay 0) "fixes" the problem, but > it's not meaningfull that way. > > Am I missing something? > > -- > C isn't that hard: void (*(*f[])())() defines f as an array of > unspecified size, of pointers to functions that return pointers to > functions that return void. > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Mon Apr 26 2004 - 13:39:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:52 UTC