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
