From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 20:25:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C42F106564A for ; Mon, 1 Dec 2008 20:25:55 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: from smtp.nlink.com.br (smtp.nlink.com.br [201.12.59.3]) by mx1.freebsd.org (Postfix) with SMTP id 4A2D48FC12 for ; Mon, 1 Dec 2008 20:25:54 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: (qmail 47543 invoked from network); 1 Dec 2008 20:25:51 -0000 Received: from j1.nlink.com.br (paulo@intra.nlink.com.br@201.12.59.126) by smtp.nlink.com.br with SMTP; 1 Dec 2008 20:25:51 -0000 Message-ID: <4934484F.2020104@nlink.com.br> Date: Mon, 01 Dec 2008 17:25:51 -0300 From: Paulo Fragoso User-Agent: Thunderbird 2.0.0.17 (X11/20081030) MIME-Version: 1.0 To: Tom Evans References: <4933EC58.5030204@nlink.com.br> <1228146079.4196.26.camel@localhost> In-Reply-To: <1228146079.4196.26.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 7.1 tcp problem (syncache)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2008 20:25:55 -0000 On 01/12/2008 12:41, Tom Evans wrote: > On Mon, 2008-12-01 at 10:53 -0300, Paulo Fragoso wrote: > >> Hi, >> >> We was using one machine with FreeBSD 6.4-RELEASE running >> apache-worker-2.2.3 + mysql, this server can answer high request from >> one client using ab: >> >> >> {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE >> ... >> Benchmarking ***** (be patient) >> Completed 200 requests >> Completed 400 requests >> Completed 600 requests >> Completed 800 requests >> Completed 1000 requests >> Completed 1200 requests >> Completed 1400 requests >> Completed 1600 requests >> Completed 1800 requests >> Finished 2000 requests >> ... >> {client}$ >> >> >> Using other hardware whit FreeBSD 7.1-PRERELEASE running >> apache-worker-2.2.9_5 + mysql, we have a poor result: >> >> >> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE >> ... >> Test aborted after 10 failures >> >> apr_connect(): Invalid argument (22) >> {client}$ >> >> >> Looking for a problem on new server log we found: >> >> kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry (possibly >> syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry (possibly >> syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry (possibly >> syncookie only), segment ignored >> >> All sysctl and apache conf are same on both server, is there a tcp >> problem with FreeBSD 7.x? >> >> Paulo Fragoso. >> >> > > Just to rule it out, have you tried testing using a more robust tool > than ab? ab is generally disliked by the apache devs I've met. Does it > still fall over using something like siege[1] or flood[2]? > > Cheers > > Tom > > [1] http://www.joedog.org/JoeDog/Siege > [2] http://httpd.apache.org/test/flood/ > > > We have tried siege because similar to ab configuration, but we have problem to repeat our ab tests: client$ siege -b -r1000 -c10 http://system_using_7.1-PRERELEASE HTTP/1.1 200 0.05 secs: 1948 bytes ==> /cgi-bin/path_to_program HTTP/1.1 200 0.04 secs: 1948 bytes ==> /cgi-bin/path_to_program HTTP/1.1 200 0.05 secs: 1948 bytes ==> /cgi-bin/path_to_program Segmentation fault: 11 (core dumped) same problem is happening trying old url: http://system_using_6.4-RELEASE. Have you had some advice? We are using ab since 2004 to make a historical reference for our tests for different hardware and systems. Why using same hardware to run ab we can test one server running 6.4-RELEASE but fails to teste 7.1-PRERELEASE? New way to answer request in 7.1 can crash ab at another machine? We are suspecting there is a new limit in 7.x which not clear for us yet. Paulo.