From owner-freebsd-performance@FreeBSD.ORG Fri Jan 14 11:14:16 2005 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 455AC16A4CE for ; Fri, 14 Jan 2005 11:14:16 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBA1F43D41 for ; Fri, 14 Jan 2005 11:14:15 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so327737rna for ; Fri, 14 Jan 2005 03:14:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=EqzT4Ovd5DvZt4IrYS4myT51J+12oapOlIPtiudFjyPJrerzD+MmDxFZ3r1jaxl3b23OXM7VhflDiX6wyoUr4SMuXwe0MLNQrHBdUcnwXNArCJsx+ApHMBHMHZcKF5+PjzKDhf+oeeywVFG/FGkuCUB63m2+Ch0NUgjtsYJAlgs= Received: by 10.38.161.11 with SMTP id j11mr80506rne; Fri, 14 Jan 2005 03:14:15 -0800 (PST) Received: by 10.38.149.29 with HTTP; Fri, 14 Jan 2005 03:14:15 -0800 (PST) Message-ID: <79722fad0501140314482620dd@mail.gmail.com> Date: Fri, 14 Jan 2005 11:14:15 +0000 From: Vlad GALU To: freebsd-performance@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Subject: Re: Tool for testing Concurrent TCP Streams X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Vlad GALU List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 11:14:16 -0000 On Fri, 14 Jan 2005 10:59:57 +0100, Eddie Oleary (BH/LMI) wrote: > A Chairde, > > Can anybody point me to a tool that will allow me to generate 15,000 + concurrent TCP streams as I want to test a system , and see how many concurrent streams > the client can handle before stopping. It will usually handle no more than min(max server descriptors, max client descriptors). In terms of performance, I don't know if 'to handle' is a correctly chosen word. It depends heavily on whatever I/O notification mechanism it uses, on both sides. The client/server connection won't 'stop' at all, it's just that you won't be able to open another paralel connection towards the server at some point. > > Slan / Ed > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it.