I am "laser focussed" performance, because we have a very performance critical project. So this is special for my use case and I agree with you this is not an all-day requirement and many other appliciations have different needs and weight other features more important. However for me its important to get a raw feeling of how big a framework's tradeoff is (compared to handrolled special implementation). And I think (after I changed the config), Akka is doing well here no doubt. The 1 million messages with tiny jobs test is kind of a smoke test crying for contention effects.
regards, Rüdiger Am Dienstag, 7. Januar 2014 22:49:11 UTC+1 schrieb Justin du coeur: > > Coming into this from the outside (as an Architect who is building serious > systems with Akka, not a member of the team), this struck me as a Big Red > Flag: > > On Tue, Jan 7, 2014 at 3:16 PM, Rüdiger Möller <[email protected]<javascript:> > > wrote: > >> As long synchronous results are forbidden, this does not affect >>> functionality or behaviour of an Actor. >>> Yes, it *may* happen the receiver blocks due to ill behaviour. >>> >> >> > Which is not an appropriate solution for non-academic software, if I >> may say so. >> >> I'd consider it a bug which should be fixed pre-production. There are >> classes of errors which cannot and should not get "repaired" at runtime, at >> least not with such a high price. >> > > I kind of wonder if you're missing the *point* of Akka. Seriously -- read > more deeply into the system, and especially the "let it fail" mentality. > It sounds to me like you're laser-focused on speed, and missing the point > that robustness in the face of errors is a much higher priority in the Akka > ecosystem. There's a pretty deeply-baked philosophical viewpoint that real > code *always* has bugs, and the highest priority is to put clear bounds on > how much those errors can cascade. > > Speaking as a consumer of the system, I honestly find the benchmarks kind > of irrelevant. I mean, saying that Akka isn't as fast as a hand-rolled > system is simply stating the obvious: it's a big, complex and fairly mature > framework, and that *always* comes at a price, since it has to trade off > competing priorities. Frankly, I'm pleasantly surprised that the folks in > the team can get speeds that are so *close* to your hand-rolled, given that > Akka's trying to do a great deal more and has never been portrayed as the > fastest thing on earth. > > Can it be optimized further? Wouldn't surprise me, and I'm sure that the > team is open to practical suggestions. But it's plenty fast *enough* for > nearly all practical purposes, scalable to larger farms than I'm ever > likely to need, and most importantly provides a really deep, robust and > easy-to-use toolset for me to build upon. That matters a great deal more > than raw speed in most situations... > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> 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/groups/opt_out.
