Hi Endre, Yeah, I understand, I posted the article because of what it states, it seems that Netty 3 didn't use any of the nice features of Java NIO making it inefficient to a point so there is a noticeable difference between the two *-according to the article-*
> Was it worthwhile to make such big changes? Because of the changes mentioned above, Netty 4 has no backward > compatibility with Netty 3. It means our projects built on top of Netty 3 > as well as other community projects have to spend non-trivial amount of > time for migration. Is it worth doing that? > We compared two echo <http://en.wikipedia.org/wiki/Echo_Protocol> protocol > servers built on top of Netty 3 and 4 respectively. (Echo is simple enough > such that any garbage created is Netty’s fault, not the protocol). I let > them serve the same distributed echo protocol clients with 16,384 > concurrent connections sending 256-byte random payload repetitively, nearly > saturating gigabit ethernet. Also because it would give a better idea of price/value gained by either doing any of the following two, hypothetically speaking assume the following guessed numbers in effort and result: - *Solution A:* Migrate akka-remote from Netty 3 to 4 and gain 4 times the performance with an effort equivalent to N hours. - *Solution B:* Migrate akka-remote from Netty 3 to akka-streams and gain 5 to 6 times the performance with an effort equivalent to 3 x N hours. The key question, is it worth effort of N x 2 extra hours for 1 to 2 times the performance which might translate to a diminishing return? That is the reason why I posted the article though in the long run *solution B is better, faster and under your philosophy of the Type Safe products*, but maybe solution A is even less than N hours, all this of course, hypothetically speaking and subjected to these assumptions being completely wrong. Regards, Guido. On Friday, January 22, 2016 at 10:02:46 AM UTC, Akka Team wrote: > > Hi Guido, > > This is one of the backlog tickets that I hope to work on at some point. > One one hand, the situation has not changed much, this is still not planned > in the near future. On the other hand, streams is finally moving into > master and 2.4, therefore we have the foundation that we can use for a > simpler and more efficient remoting layer. > > -Endre > > On Thu, Jan 21, 2016 at 4:59 PM, Guido Medina <[email protected] > <javascript:>> wrote: > >> At the moment using Akka 2.4.1 with Kryo serialization my total cost of >> messages travelling from Node A to B and then to C varies from 2ms to 3ms, >> found an interesting article that maybe could help in the future: >> >> https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead >> >> I'm just trying to keep this post alive without much pressure, it would >> be nice to see if the community has any updates/ideas. >> >> On Tuesday, October 20, 2015 at 1:00:16 PM UTC+1, rkuhn wrote: >>> >>> Thanks, Filippo! >>> >>> Concerning reaching for other tools where appropriate: there is >>> https://github.com/StefanE/AkkAeron but I have not yet tried it >>> out—this might be a viable approach, too, that punts on location >>> transparent ActorRefs in exchange for high performance right now. >>> >>> Regards, >>> >>> Roland >>> >>> 20 okt 2015 kl. 13:55 skrev 何品 <[email protected]>: >>> >>> HFT is really different I think,could not only depends on one framework >>> to solve them all.Akka is really great ,as one of my mate said when he is >>> reading ```java concurrency practice```,we would have failed without select >>> Akka as our game server base. >>> >>> Akka/erlang or any other language/framework is very great but still >>> could not cover all the area,that's why we need some special handle and >>> some best practice too. >>> >>> 在 2015年10月20日星期二 UTC+8下午7:04:27，Filippo De Luca写道： >>>> >>>> Hi Roland, >>>> This is a very good and honest insight view of the Akka roadmap. You >>>> are doing an extreme good job with the Akka project. I hope the team will >>>> get bigger without compromising the quality. >>>> >>>> Best Regards. >>>> >>>> On 20 October 2015 at 11:13, Roland Kuhn <[email protected]> wrote: >>>> >>>>> Guido, you are right that remote communication is key to what Akka is >>>>> all about. The main hindrance in terms of implementation improvements is >>>>> that there is a rather large complexity overhead incurred by >>>>> >>>>> - supporting bidirectional TCP usage >>>>> - guaranteeing per-pair ordering with at-most-once semantics (*) >>>>> - … across connection failures >>>>> >>>>> I’d very much like to dump as much of the baggage as possible to make >>>>> headway, but this will mean that we become (even) more opinionated in >>>>> terms >>>>> of where Akka Cluster is applicable—I’d envision it to be targeted at >>>>> localized deployment within the same rack or data center so that we can >>>>> go >>>>> beyond TCP. The (*) point is not negotiable, though. >>>>> >>>>> One thing that might not be widely known—despite there being no secret >>>>> about it—is that the Akka team at Typesafe is not actually that big, we >>>>> cannot do all things at once. We are right now in a position where we >>>>> must >>>>> finish what we began, we cannot leave Streams & HTTP in this >>>>> half-finished >>>>> state, with lots of performance and API improvements lying on the table. >>>>> And to make in particular Streams more widely applicable we also need to >>>>> work on getting more data sources and sinks integrated with it, either >>>>> directly or via Reactive Streams interfaces. >>>>> >>>>> This means that there is no wiggle room for us in the near term future >>>>> to tackle such a large new topic as re-envisioning the remoting >>>>> implementation. Such an effort could start small, though, and it could >>>>> also >>>>> start outside of the core team. I’m absolutely ready to support any such >>>>> initiative, e.g. by making sure that the RemoteTransport interface is >>>>> high-level and accessible enough to make an alternative transport not >>>>> only >>>>> possible but also successful. >>>>> >>>>> Ideas could be to use Aeron in terms of a communication model (e.g. by >>>>> switching off redeliveries since we don’t need them) or to research >>>>> QUIC—but a pure UDP transport would also be interesting to explore in >>>>> order >>>>> to see which “connection-like” features we really need (which I guess to >>>>> be >>>>> extremely little). >>>>> >>>>> This is surely not satisfying in the short term but as other people >>>>> say: I want a pony! (I actually want a time machine …) >>>>> >>>>> Regards, >>>>> >>>>> Roland >>>>> >>>>> 20 okt 2015 kl. 11:41 skrev Guido Medina <[email protected]>: >>>>> >>>>> If I have to give up on Akka remote because it is slow, I'll just >>>>> switch to something like Vert.x, not sure what's going on here or why it >>>>> has such little importance when it is part of Akka selling speech: >>>>> "Location transparency" or is it only an advertisement but not used much >>>>> in >>>>> practice because of its performance? >>>>> >>>>> I think Akka remote performance is a very important aspect for Akka >>>>> and should deserve a higher priority but hey, I'm only one Akka user >>>>> maybe >>>>> the other thousands think otherwise. >>>>> >>>>> On Tuesday, October 20, 2015 at 8:02:40 AM UTC+1, 何品 wrote: >>>>>> >>>>>> I rewrite it with akka-io-netty ,it has the same api as the >>>>>> akka-io,and then redo the transport based on it.but my company asked me >>>>>> to >>>>>> delete it from the github.so sorry.and the link below is unmatained and >>>>>> we >>>>>> are not using it in production any more. >>>>>> and I think for the really HT,you could do the things like: >>>>>> 1,reduce context switch >>>>>> 2,reduce gc pressure >>>>>> 3,quick serialization >>>>>> 4,don't using tcp >>>>>> 5,don't using akka remote directly >>>>>> >>>>>> If I was you ,I would start a dedicated endpoint for the exchange >>>>>> ,which may be based on Aeron or Netty4 with UDT.only by using >>>>>> akka-stream >>>>>> and netty4 will not make it works here I think,5 ms,need some special >>>>>> work. >>>>>> >>>>>>> >>>>> -- >>>>> >>>>>>>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> *Dr. Roland Kuhn* >>>>> *Akka Tech Lead* >>>>> Typesafe <http://typesafe.com/> – Reactive apps on the JVM. >>>>> twitter: @rolandkuhn >>>>> <http://twitter.com/#!/rolandkuhn> >>>>> >>>>> >>>>> -- >>>>> >>>>>>>>>> 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. >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> [image: --] >>>> Filippo De Luca >>>> [image: http://]about.me/FilippoDeLuca >>>> <http://about.me/FilippoDeLuca?promo=email_sig> >>>> >>>> >>> >>> -- >>> >>>>>>>>>> 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. >>> >>> >>> >>> >>> *Dr. Roland Kuhn* >>> *Akka Tech Lead* >>> Typesafe <http://typesafe.com/> – Reactive apps on the JVM. >>> twitter: @rolandkuhn >>> <http://twitter.com/#!/rolandkuhn> >>> >>> -- >> >>>>>>>>>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/akka-user. >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Akka Team > Typesafe - Reactive apps on the JVM > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
