Re: Unexpected low CPU usage

Some further questions/ points:

1. The Apache Commons HttpClient's keep-alive functionality works and,  
in general, is more stable than Sun's default implementation. The  
expected usage of this class is to use use a single shared instance  
and to use MultiThreadedConnectionManager when concurrent requests are  
being made.

2. I'm assuming the following:
        - that you started with -Dhttp.keepAlive=true
        - your code (or the code it calls) explicitly calls close() on the  
HttpConnection's InputStream when it has finished reading the response.
        - you are not using HTTPS

3. Assuming you are now past the initial problem with excessive  
connections being left in TIME_WAIT state, you didn't mention what  
this system will do and how it will be used.

In your first email you mentioned that your goal is to test the  
overhead of your framework. That won't be realized with this setup,  
which isn't really simulating a physical network connection. To  
understand the overhead the test physical architecture, and  
specifically the network latency should be roughly comparable.  
Published studies that compare the performance of Soap and RMI  
typically report an order of magnitude difference. I don't understand  
why anyone would choose to use Soap if they have control of both  
client and server - choosing complexity, bloat, and immature test tools.

Good luck with your project. If your system has high usage you may  
want to reduce the time_wait_interval to something better suited for  
web servers. YMMV


On Jan 21, 2008, at 3:21 PM, Johan Stuyts wrote:

>> What happened to the throughput when you enabled keep-alive?
>
> I investigated a bit more and here is the whole story.
>
> Apache XML-RPC does not use Commons HttpClient by default, but  
> instead it
> uses the Sun HTTP implementation. Keep-alive is enabled and does *not*
> cause performance problems.
>
> When I switched to the transport factory that uses Commons HttpClient
> which is included with Apache XML-RPC. This led to the problems with  
> too
> many ports in the 'TIME_WAIT' state. I looked in the code and saw an
> HttpClient was created for each request.
>
> I wrote a transport factory that uses a single HttpClient with a
> MultiThreadedConnectionManager for all requests. HttpClient by default
> uses keep-alive too. The performance of XML-RPC dropped and CPU usage
> became much lower.
>
> I am determining how easy it is to switch XFire to the Sun HTTP
> implementation. If it is not easy I will see if switching to CXF  
> helps. I
> have to switch anyway some time in the future as further development  
> will
> be done at CXF.
>
> Note that I still used a single client with a single thread for all  
> three
> configurations above.
>
> Johan Stuyts
>
> ===================================
> This list is hosted by DevelopMentor®  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com
>

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com