You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2006/08/31 20:02:09 UTC
[HttpCore] NIO extensions (first take) are ready for review
Folks,
NIO extensions (first take) are ready for review. Feel free to take a
look and let me know what you think. Feedback, suggestions, critique
will be highly appreciated.
I wrote a short description of the HttpCore NIO API the best way I
could:
http://wiki.apache.org/jakarta-httpclient/HttpCoreNioApi
There are also a couple of samples to show the new API in action.
It is premature to draw any conclusions yet but preliminary test results
show that NIO tends to perform significantly worse under heavy load than
the classic I/O. I'll be doing more tests with various scenarios (small/
large content entities, POST/GET request types, lots of idle connections
and a few ones under heavy load, and so on) to make the picture more
complete.
Oleg
=============================================
HttpCore on MINA
=============================================
Server Software: MINA-HttpServer/1.1
Server Hostname: localhost
Server Port: 8080
Document Path: /index.html
Document Length: 12928 bytes
Concurrency Level: 50
Time taken for tests: 42.598608 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 100000
Total transferred: 1308751914 bytes
HTML transferred: 1293048774 bytes
Requests per second: 2347.49 [#/sec] (mean)
Time per request: 21.299 [ms] (mean)
Time per request: 0.426 [ms] (mean, across all concurrent
requests)
Transfer rate: 30002.81 [Kbytes/sec] received
=============================================
HttpCore (NIO)
=============================================
Server Software: Jakarta-HttpComponents-NIO/1.1
Server Hostname: localhost
Server Port: 8080
Document Path: /index.html
Document Length: 12928 bytes
Concurrency Level: 50
Time taken for tests: 46.386961 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 100000
Total transferred: 1309763840 bytes
HTML transferred: 1292960480 bytes
Requests per second: 2155.78 [#/sec] (mean)
Time per request: 23.193 [ms] (mean)
Time per request: 0.464 [ms] (mean, across all concurrent
requests)
Transfer rate: 27573.83 [Kbytes/sec] received
=============================================
HttpCore (classic)
=============================================
Server Software: Jakarta-HttpComponents/1.1
Server Hostname: localhost
Server Port: 8080
Document Path: /index.html
Document Length: 12928 bytes
Concurrency Level: 50
Time taken for tests: 26.785007 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 100000
Total transferred: 1309278552 bytes
HTML transferred: 1292877568 bytes
Requests per second: 3733.43 [#/sec] (mean)
Time per request: 13.393 [ms] (mean)
Time per request: 0.268 [ms] (mean, across all concurrent
requests)
Transfer rate: 47735.36 [Kbytes/sec] received
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpCore] NIO extensions (first take) are ready for review
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> Sure. Some people just insist on being able to write directly to the
> output stream. I want to demonstrate that this is possible with the
> HttpCore API. I am not trying to say this approach is any better than
> using StringEntity.
Ok, then it is just the example which I don't like :-)
> Now the Evil Plan (TM) is to start working on a asynchronous version of
> HttpService that decouples the process of receiving HTTP requests,
> generating response content and sending off resultant HTTP responses
> using a fixed pool of worker threads. I am not sure how exactly this is
> going to work (if at all) but I want to keep this idea on the back
> burner for some while.
Sounds pretty much like what I'm heading to on the client side with
HttpDispatcher. Sooner or later (I'm afraid later) I'll reach the
point where I have to look into NIO in order to avoid having one
worker thread per connection just to detect incoming responses.
Lifting NIO up to the API itself would probably require rewriting
half of HttpCore. There's no point in thinking about that until we
have much more contributors.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpCore] NIO extensions (first take) are ready for review
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2006-09-03 at 09:21 +0200, Roland Weber wrote:
> Hi Oleg,
>
Hi Roland
> here are a few comments, though they have little to do with NIO.
>
> - the examples and at least some of the implementation classes
> are missing the Apache copyright notice in the source files
>
I'll fix that.
> - I still don't like the duplication of methods in IOSession
> and HttpContext. The only reason I can see for not deriving
> IOSession from HttpContext are the constants defined there.
> Maybe we should separate declaration of the methods from
> definition of the constants. Factor out the methods to a new
> interface o.a.h.util.Attributable, derive both HttpContext
> and IOSession from there?
>
I didn't want to make the public interfaces in the NIO module dependent
on HTTP specific interfaces unnecessarily. I do not see a problem with
deriving IOSession from HttpContext, though.
> - The way you are using EntityTemplate in the examples,
> I don't see the advantage over a StringEntity. For example:
>
> EntityTemplate body = new EntityTemplate(new ContentProducer() {
> public void writeTo(final OutputStream outstream)
> throws IOException {
> OutputStreamWriter writer =
> new OutputStreamWriter(outstream, "UTF-8");
> writer.write("<html><body><h1>");
> writer.write("File ");
> writer.write(file.getPath());
> writer.write(" not found");
> writer.write("</h1></body></html>");
> writer.flush();
> }
> });
>
> can be replaced by
>
> StringEntity body =
> new StringEntity("<html><body><h1>" +
> "File "+file.getPath()+" not found" +
> "</h1></body></html>",
> "UTF-8");
>
> which is just as readable and doesn't need an inner class.
>
Sure. Some people just insist on being able to write directly to the
output stream. I want to demonstrate that this is possible with the
HttpCore API. I am not trying to say this approach is any better than
using StringEntity.
>
> The main problem I had with understanding your NIO activities
> is now solved. I was always wondering how you were going to
> expose the channels at the entities so applications can use
> NIO features. From what I've seen now, you just don't.
> Applications continue to use blocking streams, which are then
> mapped to channels. Doesn't that mean that the context switches
> you want to avoid are just moved from the general IO operations
> to the NIO receiver/transmitter?
>
I _may_ be wrong here, as I do not have any empirical data to back up
this claim with, but I _believe_ this approach nonetheless requires less
context switching. The worker threads are blocked waiting on a mutex
instead of a network socket. They will not be woken up just to see if
there is any incoming data available.
Of course, this approach does not solve one thread per connection
problem, it merely mitigates it. HttpCore NIO is meant to be just a
foundation asynchronous services could be built upon.
Now the Evil Plan (TM) is to start working on a asynchronous version of
HttpService that decouples the process of receiving HTTP requests,
generating response content and sending off resultant HTTP responses
using a fixed pool of worker threads. I am not sure how exactly this is
going to work (if at all) but I want to keep this idea on the back
burner for some while.
Cheers
Oleg
> cheers,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpCore] NIO extensions (first take) are ready for review
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
here are a few comments, though they have little to do with NIO.
- the examples and at least some of the implementation classes
are missing the Apache copyright notice in the source files
- I still don't like the duplication of methods in IOSession
and HttpContext. The only reason I can see for not deriving
IOSession from HttpContext are the constants defined there.
Maybe we should separate declaration of the methods from
definition of the constants. Factor out the methods to a new
interface o.a.h.util.Attributable, derive both HttpContext
and IOSession from there?
- I will have to update build files so that the examples are
compiled and javadoced.
- The way you are using EntityTemplate in the examples,
I don't see the advantage over a StringEntity. For example:
EntityTemplate body = new EntityTemplate(new ContentProducer() {
public void writeTo(final OutputStream outstream)
throws IOException {
OutputStreamWriter writer =
new OutputStreamWriter(outstream, "UTF-8");
writer.write("<html><body><h1>");
writer.write("File ");
writer.write(file.getPath());
writer.write(" not found");
writer.write("</h1></body></html>");
writer.flush();
}
});
can be replaced by
StringEntity body =
new StringEntity("<html><body><h1>" +
"File "+file.getPath()+" not found" +
"</h1></body></html>",
"UTF-8");
which is just as readable and doesn't need an inner class.
The main problem I had with understanding your NIO activities
is now solved. I was always wondering how you were going to
expose the channels at the entities so applications can use
NIO features. From what I've seen now, you just don't.
Applications continue to use blocking streams, which are then
mapped to channels. Doesn't that mean that the context switches
you want to avoid are just moved from the general IO operations
to the NIO receiver/transmitter?
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org