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
