I was also surprised by the results when I saw them.
This was a C++ project, not java, but the performance characteristics
wouldn't be any different.
This was also proprietary project for one of my old companies so I can't
divulge anything else about it.
What I can tell you, it comes down to a very simple fact:
In all async servers, any single I/O operation comes down to 2 calls:
poll() (or whatever equivalent you want to use) and read/write()
There is also setup costs for poll() or its equivalents that are not
present in a synchronous server.
With synchronous server, there is no poll(), just the read and write, thus
the overhead of the poll() and its setup is eliminated.
Now it all comes down to the OS threading and I/O performance, and the
real surprise was that the multiple threads,
even 100s of thousands of them, all doing IO were not bogging down the
system at all.
I know that there is all hype right now around async servers, but in real
world, async is just slow.
I also believe that lightweight threads (green_threads, I believe) were
eliminated from the JVM long time ago.
On Jan 24, 2013, at 7:51 PM, Robert Zeigler wrote:
I find this very difficult to swallow, at least for java apps, unless,
maybe, you're using a java implementation that uses native threads instead
of lightweight java threads, then I might believe it. I would also believe
it if the async server is poorly written. And I can believe that many an
async server is poorly written. It also depends a LOT on whether your
connections are short or long lived. For something like a web server where
you typically have very short-lived client connections, I can also believe
this. I'm rather skeptical of general claims that an async server is
slower, and would love to see some of the "space research project" worth of
data backing the claims.
Robert
On Jan 24, 2013, at 1/249:29 AM , Lenny Primak <lpri...@hope.nyc.ny.us>
wrote:
I've done extensive ( no, not extensive, really, really, extensive,
worthy of a space research project extensive ) testing of async IO
performance vs. threaded server performance.
The conclusion is that unless you have over 10,000 active, users,
async IO is about 1/2 the performance of the usual thread-per-connection
performance.
By active users I mean connections that are actually putting out IO all
the time, as opposed to just idle sitting connections.
If you really, really, do have that many uses ( amazon.com type shop )
your bottleneck won't be at the web server level anyway, so the right thing
to do is to load balance and scale out.
Async IO won't solve any of these problems and will just introduce bugs
and complexity and actually degrade performance by significant margin.
On Jan 24, 2013, at 7:06 AM, "Thiago H de Paula Figueiredo" <
thiag...@gmail.com> wrote:
On Thu, 24 Jan 2013 09:26:45 -0200, Muhammad Gelbana <
m.gelb...@gmail.com> wrote:
Can someone clarify why would play! be better than tapestry in this
test?
I guess only someone with play! internal architecture can tell you
this for sure. I also think that is probable that its usage of Netty (
https://netty.io/), which uses NIO and asynchronous IO, instead of
servlet containers (usually synchronous) is an important factor. I'm
playing with the idea of running Tapestry over Vert.X (http://vertx.io/),
but no code written yet.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
