Hello Reid,
It seems you’re asking about performance of *akka-streams* not of *akka-io*,
as seen by your mention of outgoingConnection - do not confuse these two
modules.
The current performance of akka-streams has not been tuned at all, we know
and have been quite vocal about it during it's releases.
The current akka-streams releases are meant to gather feedback mostly about
API decisions. Performance has not been tuned yet *at all*, so it is to be
expected for it to currently be slow.
We focused completely on getting the infrastructure and models right for
the last months, having this now all fall into place, we can move on to
optimisation work.
If you ("right now") want high performance for IO things, fall back to our
actor based IO impl: http://doc.akka.io/docs/akka/2.3.9/scala/io.html
and do not use streaming-io for performance sensitive things unless you
understand that it's under heavy development and currently will be still
slow.
We'll get to optimising akka-streams very soon, and then you can expect
nice performance from it.
-- Konrad
On Mon, Feb 23, 2015 at 9:36 AM, Reid Spencer <r...@reactific.com> wrote:
> 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.
>
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
>>>>>>>>>> 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.
