Hi Adam, Comments inline …
> On Feb 23, 2015, at 2:19 AM, Adam <adamho...@gmail.com> wrote: > > I think the OS you're using matters a lot for this sort of test. Hopefully > it's not windows… No, it is Mac OSX Yosemite 10.10.2. I realize that absolute measurements on this kind of machine are not necessarily accurate but I’m really only interested in relative measurements. What I am doing is running the YCSB benchmark <https://github.com/reactific/YCSB> between the standard Java Mongo driver and my RxMongo driver. The standard Java driver just uses plain old thread-per-connection blocking socket communications to the mongo daemon. My RxMongo driver uses Akka IO TCP OutGoingConnection. Given that both are run on the same exact machine, I expect that comparing the two over enough iterations on an otherwise idle machine should be statistically sound. Now, if the two were less than 10% apart on their numbers, I wouldn’t have written here as that could be accounted as noise. But when the numbers are off by 100-600%, I’m pretty certain the implementation approach is at fault. > > What was the maximum concurrency level that you've tested? I’ve varied it between 1 thread and 50 threads in the YCSB client. My machine has 8 cores, 16 with hyper threading. However, the tests I’ve been reporting have been with 1 thread. > Did you make sure (in the performance test code) that this concurrency level > is actually met in all cases? > Did you try tweaking with the socket options (e.g. increase the read/write > buffers)? The only one’s I set are the ones provided by Akka.TCP’s SocketOptions. I set: tcpNoDelay : Boolean = true, tcpKeepAlive : Boolean = true, tcpOOBInline : Boolean = false, I’m unsure what the Java Mongo driver does but I’d be surprised if it did anything spectacular. If you think this is significant, I could research that. > It would be interesting indeed to know about ACK/NACK. > I'm using the approach of using NACK until I get failure => buffer until > getting the resumed message => recover using ACKs.=> go back to NACK once the > buffer is cleared. > I guess it means less total messages traveling back and forth. I suppose it would. It is certainly worth looking at. In researching interaction with mongo, however, I’ve discovered that it utilizes a strict request/response protocol (per connection) so if I write a 2nd request before the first one has finished, I lose the response to the first. Consequently, I don’t write until I have both the ACK and a response. Stacking up writes, even if they could be done faster, just doesn’t help. So, I’m not sure writing until failure would be profitable in this case. 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
