commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject javaflow and SEDA networking
Date Thu, 28 Aug 2008 17:28:02 GMT
Hi all,

I want to share some experiment I did with javaflow applied to networking.

I mean nowadays everyone doing networking is using SEDA based solutions, 
but you know writing event based code is much more complex than writing 
plain old synchronous code.

So I asked myself: will javaflow be performant enough in a similar use 
case? I decided to answer myself by writing a small proof of concept.

I want to get a synchronous network client and make it run 
asynchronously without altering its code, because the code is much more 
clean to be read than a SEDA/event based approach.

I know continuations libraries have to do much with the stack/local 
memory and they may be a performance bottleneck, but I wanted to give it 
a try and understand the real overhead.

Here is a Proof of Concept:

My dummy synchronous client:
http://people.apache.org/~bago/netflow/site/xref/org/apache/james/netflow/rewrite/TesterClient.html

The network abstraction is the Transport: basically it allow you to
read/write lines in a blocking way.
http://people.apache.org/~bago/netflow/site/xref/org/apache/james/netflow/Transport.html

As the first step I implement an "in vm" test that simply implements the
above transport using mina against a mina backed Echo-VMPipe-transported
server.

Here is the mina transport:
http://people.apache.org/~bago/netflow/site/xref/org/apache/james/netflow/MinaTransport.html

Now I want to make it asynchronous without changing the TesterClient
source code.

I wrote a ContinuingMinaTransport:
http://people.apache.org/~bago/netflow/site/xref/org/apache/james/netflow/rewrite/ContinuingMinaTransport.html
this transport simply take care to suspend the execution of the program
each time an IoFuture is submitted.
It stores the current future in the Continuation context
(http://people.apache.org/~bago/netflow/site/xref/org/apache/james/netflow/MinaFutureContext.html)


and then suspend.
At the same time it also adds a the MinaFutureContext as a listener of
the future. The MinaFutureContext will notify its parent
MinaContinuationContext object when this future is ready so that the
continuation executor can "continue" the processing for this session.

The MinaContinuationContext simply have a map of futures and their
associuated suspended continuation, and then have a list of ready to be
resumed futures.

MinaFutureContext.getReadyContext() returns if the processing is
completed otherwise block until a future is completed and ready to be
processed.

Here is the main test class:
http://people.apache.org/~bago/netflow/site/xref/org/apache/james/netflow/Test.html

Note that I have to use a ContinuationClassLoader and a factory in order
to let javaflow instrument my protocol classes and make them suspendable.

The test simply run the protocol either in standard mode or in the
SEDAted/continuation mode. It runs 1000 transactions in threadNumber
threads.

And here are the results for a single thread:
1) synchronous, sequential connectiosn: 1000ms
2) SEDAted classes: 4000ms

1000 connections means 10000 reads + 10000 writes, so a total of 20000
events (and continuations).

This would mean that the overhead for 20000 continuations is less than 
3000 ms, so nearly 150 microseconds per continuation.

I think this is an interesting result because this should show the
overhead of javaflow in the worst scenario. IN fact I have an in jvm
protocol so there is no delay at all for the network, but if I simply
add 1ms of delay for every read/write action the synchronous runner will
of course take 20 seconds more, while the SEDAted runner will run
smoothly and without using 1 thread per connection.

If anyone wants to play with the code I uploaded it to my p.o.a home:
http://people.apache.org/~bago/netflow/

WDYT? Is this an useless approach? Does it worth using continuations and
SEDAified protocols instead of 1 thread per connections or the
continuations overhead is greater than the overhead the standard threading?

I also thought that in a similar use case the continuation could be 
triggered after a given delay so that we don't spend time 
suspending/resuming when the answer is fast and we do that only when 
there is a real wait time to be spent on something else.

I tried to conditionally suspend only after "await" 1 millisecond to see 
the performance impact of running instrumented code without suspending 
it. I added this 1ms wait to every blocking call and the time now is 1500ms.

Considering that this is only a PoC I set up in few hours I found it 
very interesting and I decided to share this with you!

Javaflow is great!
Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message