hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HC 5.0 scope and design decisions
Date Wed, 28 Sep 2016 17:53:52 GMT
On Wed, 2016-09-28 at 18:40 +0300, Dmitry Potapov wrote:
> Oleg,
> 

Hi Dmitry

> I'm not sure I got it right.
> Are you going to drop org.apache.http.protocol.HttpService class?

Yes, I do.

> For now it is the only way to:
>  1. Process full-duplex requests (i.e. start sending reply before complete request entity
consumption)

Full-duplex data transfer should be massively easier with non-blocking
I/O. If it is not, it is a problem with the actual non-blocking code.

>  2. Compless/decomplress requests and responses on the fly (DecompressingEntity really
does the job for servers). This is possible for NIO too, but will require to implement non-blocking
analog for GzipInputStream.

Very true. However we likely will have to do it anyway if we want HTTP/2
code to support transparent content compression / decompression. 

>  3. Reduce threads contention by using fixed number of workers with connections queue.
This allows to limit CPU usage with native system mechanisms: you spawn 4 threads and you
know that only 4 requests and responses will be served simultaneously, without excessive context
switching and risk of response being blocked by other heavy task.

Exactly the same can be done with non-blocking code very easily as long
as one can live without InputStream / OutputStream compatibility.

>  4. Blocking server is the only effective way to stream static files from disk, as there
is no such thing as non-blocking file channels (unless you're crazy and use direct i/o). For
instance, recent nginx versions uses separate pool with blocking operations for this task,
otherwise static files streaming will preempt other requests.
> 

Non-blocking file channels were implemented in Java 7 with NIO2, were
they not? Besides, NIO with direct channels (zero-copy mode) outperforms
classic I/O considerably when copying content directly from a file. The
problem is that HTTP/2 makes zero-copy impossible due to frame
multiplexing. 

> Every item listed above can be achieved in HttpAsyncService but this will require some
software crutches and won't allow to achieve maximum throughput and performance.
> 

There is no harm in keeping HttpService as long as people find it
useful. I just personally tend to think its usefulness will be
diminishing (beyond cases where one needs good performance and
InputStream / OutputStream compatibility).

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message