

HTTP Client Performance – IO - stefans
http://blogs.atlassian.com/2013/07/http-client-performance-io/

======
areavic
NIO has significant impact on HTTP Servers not on stand alone single instance
clients.

The only time you'd use a NIO client, is on a server - for example, when
building a caching proxy server.

The expected benefits are higher throughput of the proxy (lower CPU/RAM
consumption allows multiple clients to operate in parallel).

Individual downloads being faster was never expected to be a benefit

~~~
brazzy
> NIO has significant impact on HTTP Servers not on stand alone single
> instance clients.

This is true for the asynchronous network IO parts of NIO, but definitely not
all of it. It also enables memory mapping and DMA, two things that can have
significant impact on stand alone software.

------
laumars
Interesting article, but do many people use curl for binary downloads? I
thought most sysadmins used it for viewing headers and/or parsing raw text.
For binary downloads wget seems to be favoured. So with that in mind, I'd be
curious to see how wget compared with the other solutions in those benchmarks.

DISCLAIMER: I'm not trying to imply that my way is "better" nor the only way
HTTP GETs should be called. I'm only commenting on how I generally work and
the trend I've anecdotally observed. Though I'd be interested to see if many
others on here do prefer curl over wget for pulling binary files.

~~~
klausa

      [13:17:18] i13:klausa:~% uname -a
      Darwin i13.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May  1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
      [13:17:19] i13:klausa:~% curl
      curl: try 'curl --help' or 'curl --manual' for more information
      [13:17:22] i13:klausa:~% wget
      wget: Command not found.

~~~
Achshar
and this is...?

~~~
laumars
A demonstration about how OS X ships curl but not wget. Essentially he's just
running

    
    
        which {curl,wget}
    

to demonstrate that curl is in $PATH where as the shell cannot find wget
(since we're talking about base installs it's safe to assume that the
aforementioned utilities should be in $PATH by default - if included at all).

~~~
Achshar
Thanks, that makes sense now.

------
shimms
For those (like me) who didn't know what NIO was, and got lost in the second
paragraph, from Wikipedia:

"The APIs of NIO were designed to provide access to the low-level I/O
operations of modern operating systems. Although the APIs are themselves
relatively high-level, the intent is to facilitate an implementation that can
directly use the most efficient operations of the underlying platform."

[http://en.wikipedia.org/wiki/New_I/O](http://en.wikipedia.org/wiki/New_I/O)

------
WatchDog
It's an interesting subject, I just wish his benchmarks were much more
indepth. I would like to how the amount of sequential iterations of the code,
the HTTP Server, JVM, OS, kernel, latency, jitter all affect the performance.

~~~
ShabbyDoo
Yes. JVMs are slow for short-lived program executions compared to native code.
By default, Hotspot does not compile a method until it is executed 10K times.
Most libraries in the Java ecosystem are written to optimize performance over
a long execution lifespan at the possible expense of startup time. The Apache
HTTP libraries allow pooling of threads, HTTP keep-alive as an implementation
detail, buffer re-use, etc. So, evaluating these libraries by starting up a
new JVM for each run inherently tests them under a circumstance for which they
were not designed/optimized. Gradle (a build tool) sort of solves the problem
of short-run invocations by forwarding command line requests to a long-running
Java background daemon.

------
bhauer
Thanks for doing this! A very useful set of results!

I'd be curious to see how these each behave when needing to manage concurrent
HTTP connections, fetching files from an ultra-fast server such as Netty,
nginx, or Undertow.

Say 64, 128, 256, maybe even more simultaneously.

