On Mon, Apr 06, 2009 at 03:13:12PM +0300, Tuomas Makinen wrote:
> > On Mon, Apr 06, 2009 at 02:16:05PM +0300, Tuomas Makinen wrote:
> >> Hi,
> >>
> >> I'm facing a weird problem when using HttpCore & NIO-extension to send
> >> multiple requests using one connection.
> >>
> >> I have custom build performance load testing tool that is used to test
> >> our
> >> application and it's working otherwise well except for one thing:
> >>
> >
> > Tuomas,
> >
> > Firstly, a general design question. Why would you want to use NIO on the
> > client side in the first place, especially for a performance testing
> > tool?
> 
> I want to use NIO because we need huge number of concurrent users and
> therefore I see NIO as most performing way to achieve this. We need over
> 1000 concurrent connections per test machine to server and by using
> NIO-extension and few threads for IOReactor dispatching we can achieve
> this without threading overhead that would be caused by creating separate
> threads for each connection and for what I have tested now, it seems to
> perform pretty well.
> 

Fair enough. Actually blocking IO can easily outperform NIO with
anything less than 2000 concurrent connections on modern JVMs, but NIO
certainly could be a safer bet in case you find yourself needing to
support 2000+ connections.


> 
> >> After 100 requests sent to one connection, the framework doesn't ask for
> >> new requests from HttpRequestExecutionHandler anymore but neither is the
> >> connection closed too. Still, response has been acquired from that
> >> connection so it should block due to that.
> >>
> >> Any ideas what could be wrong?
> >>
> >
> > There is no such limit in HttpCore. However, 100 sounds like a very
> > likely limit for persistent connection re-use on the server side. Do you
> > see NHttpRequestExecutionHandler#finalizeContext even fire?
> >
> > I strongly recommend taking a look at this sample which demonstrates the
> > recommended way of managing non-blocking connections on the client side.
> >
> > http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore-nio/src/examples/org/apache/http/examples/nio/NHttpClientConnManagement.java
> 
> 
> When I started to develop this application I looked at this example:
> 
> http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore-nio/src/examples/org/apache/http/examples/nio/NHttpClient.java
> 
> and started working on that idea. I'll take a look at the example you
> provided but that limit could be also server side issue since I quickly
> modified that NHttpClient example and were able to reproduce issue by
> using that. We are currently using JBoss 4.2.3.GA as application server
> and I actually tried to quickly search for any configuration parameters
> but couldn't find any. I'll do one more test by setting up some small http
> server serving static content and see what happens with that.
>

Keep me posted.

Cheers

Oleg

> - Tuomas M.
> 
> 
> >> I tried to find any references to this problem from HttpCore &
> >> NIO-extension source codes but couldn't really find any. Ofcourse the
> >> problem might be in my code too but from that part it's pretty
> >> straighforward and I'm just fetching new requests from queue when
> >> submitRequest call occurs and I can see that always after 100 requests,
> >> it
> >> doesn't send new ones anymore.
> >>
> >> With best regards,
> >> Tuomas Makinen
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]
> >> For additional commands, e-mail: [email protected]
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to