It is also possible that you your windows box is simply overloaded processing your XML and simply can not get to service new requests in time. If you can, try to put your service on a Solaris box, or even Linux. They tend to have a little more responsive kernel and networking layer as Heitzso pointed out.
Another way to test would be to run a client that requests an html page from tomcat. This would be much lower CPU requirements per request and windows might actually keep up with the load. Taras > -----Original Message----- > From: Alan Moore [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 17, 2002 9:19 AM > To: '[EMAIL PROTECTED]' > Subject: RE: Axis performance > > > Another place to look for performance bottlenecks is in the underlying > transport (HTTP). For example, the socket "linger" setting > (SO_LINGER) and > whether or not persistent connections are being used. > > Since Tomcat is handling the server side of the > connection(s), that should > already be highly optimized. It is possible that the Axis > client side code > does not optimally set up the connections but I would be very > surprised if > this were the case. > > alan > > > -----Original Message----- > > From: Heitzso [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, May 16, 2002 4:39 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Axis performance > > > > > > 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] > > > > > > > >
