hAkkers,

One of the reasons I chose to implement my RxMongo 
<https://github.com/reactific/RxMongo> driver on Akka was because of the 
performance and scalability of spray.io which was transitioned into Akka 
IO. Having gotten far enough with my driver to have performance results 
now, I have to admit I'm a little underwhelmed with them. I've performance 
tuned all my code until it is less than 10% of the total, the rest being 
what appears to be wait time in Akka IO. At an average of 561 μs per insert 
over 10,000 requests, I'm not dissatisfied with the performance .. except 
that the non-reactive Java Mongo driver does the same workload, on the same 
machine, with the same Mongo instance, in an average of 229 μs .. more than 
twice as fast!  I am using the ACK based write throttling and doing one 
complete request/response cycle before writing another message to Akka IO. 
As far as I can tell, 78% of the total time (441 microseconds) is lost in 
the black hole between sending the request to Akka IO and receiving a reply 
from it. Now, even if the Java Mongo driver was perfect (it is not), there 
shouldn't be more than 229 μs of delay (on average) for the I/O. So, I'm 
looking for at least 200 μs lost somewhere in Akka IO. I could go into 
further detail, but this should suffice as background for my questions. 

So, I'm hoping I've done something silly with my use of Akka IO and I have 
some questions to help point me in the right direction to getting the kind 
of performance I've come to expect with Akka:

   - I have both sampled and instrumented with YourKit. It shows 90% of the 
   time in sun.misc.Unsafe.park .. most of the threads are doing nothing.  It 
   was incredibly unhelpful while investigating this problem.  To get as far 
   as I have, I've developed my own hand-instrumented profiler! 
   <https://github.com/reactific/hotspot-profiler>  So, is there a 
   performance analysis tool that is best suited for working with Akka?
   - Does Akka, and specifically Akka IO, have any performance analysis 
   instrumentation in it? I've turned on DEBUG level logging but that doesn't 
   help much with understanding performance. I turned on 
   akka.io.tcp.trace-logging but it doesn't seem to do anything.  How can I 
   find out how much time Akka IO is taking for its various operations short 
   of hand instrumenting the code myself?
   - The test I'm doing is with one thread and one actor talking to the 
   Akka IO connection. I had thought that the poor performance would get less 
   notable with more threads and actors since the claim with Akka IO is better 
   scalability, not necessarily better performance with a single thread.  But, 
   actually, Akka's relative performance gets worse with higher loads, 
   threads, actors and connections. When multiple threads, actors and 
   connections are used, the gap between the Java Mongo driver and RxMongo 
   widens until Java is 6-7 times faster at 50 connections/threads/actors. I'm 
   hoping this sounds familiar to someone who can say, "you probably forgot to 
   do X".  Anyone know what X is? :)
   - Does anyone have any performance analysis tips or tricks when working 
   with Akka IO ?  Configuration parameters? Rules of thumb? Gotchas?  

In case it matters, my Akka ActorSystem is configured like this:

actor {
  debug {
    # enable DEBUG logging of all AutoReceiveMessages (Kill, PoisonPill etc.)
    autoreceive = off
    # enable DEBUG logging of actor lifecycle changes
    lifecycle = off
    # enable DEBUG logging of all LoggingFSMs for events, transitions and timers
    fsm = off
    # enable DEBUG logging of subscription changes on the eventStream
    event-stream = off
    # enable WARN logging of misconfigured routers
    router-misconfiguration = off
  }

  # What kind of ExecutionService to use
  executor = "fork-join-executor"

  fork-join-executor {
    # minimum number of threads to cap factor-based core number to
    core-pool-size-min = 8
    # No of core threads ... ceil(available processors * factor)
    core-pool-size-factor = 2.0
    # maximum number of threads to cap factor-based number to
    core-pool-size-max = 64
  }
  # Throughput defines the maximum number of messages to be
  # processed per actor before the thread jumps to the next actor.
  # Set to 1 for as fair as possible.
  throughput = 1
}

io {
  tcp {
  }
}


My test machine is an 8-core 3GHz Intel Xeon E5 with 64GB RAM and everything 
(mongo server, RxMongo) runs locally.

TIA,

Reid.

-- 
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to