Very important to spec the OS.  For instance WinNT workstation 
and Win2K non-server versions all limit the number of concurrent
connections.  I also have a simple stress test service that I
run and I hit the connection problem quite easily on the Win non-server
platforms.

On the other hand, on Linux I easily push up to larger numbers,
but the numbers can be deceiving.  For instance, I've tried
to crank up 600 parallel threads, and on the surface it handles
this load quite well.  But I also track the maximum number of
actual threads running and that number is lower ... usually
some number less than 50.  What's happening is that it takes
X time to setup a thread and the thread then competes for resources
against other threads, so the later threads walk in late and
the early threads are finishing up.

So, unless you're tracking actual thread count and not just
the number of threads you've coded the client stress app
to crank up, I'm guessing ...
        - you're running on Win-non-server
        - you're actual thread count max'ing at 10

Heitzso



On Thu, 2002-05-16 at 15:38, Han Wang wrote:
> Hello Axis users,
> 
> I'm running preliminary tests on AXIS's ability to handle concurrent
> accesses, and am puzzled by an apparent fixed point where connections would
> be refused. At around 18-19 concurrent access to a simple web service, there
> would be:
> 
> java.net.ConnectException: Connection refused: connect
> 
> I'm running Axis beta2 and Tomcat4.0.3 on Windows2k
> 
> I've modified Tomcat's server.xml's connector acceptCount to 100, and
> minProcessors to 50 (so theoretically, there would be 50 threads waiting to
> handle request?)
> 
> Is there any other properties I have to set somewhere? Shouldn't the
> requests just be queue'd up by tomcat if it can't be handled? I'm not sure
> what's happening and the logs don's say much. Is this a Tomcat problem?
> 
> I'm using a simple client that basically creates n threads, each thread
> making the same request to the same service. at n>18, there will be the
> connection problem.
> 
> Thanks,
> Han
> [EMAIL PROTECTED]
> 


Reply via email to