You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 30, 2023. It is now read-only.
Looking through the code base of Helios, I was wondering why did you prefer to use APM socket abstractions in order to perform tcp communication in Helios? The traditional Begin/End async methods on high performance network applications (like Akka) can cause increased garbage collection due to memory thrashing when servers have many connections or when they are receiving large amounts of data.
The most performant communication abstractions for TCP available in .NET nowadays is EAP - XXXAsync methods (ConnectAsync, ReceiveAsync, SendAsync etc) which, when used with buffer pooling, they reduce considerably GC work and therefore increase the overall performance of the application.
The System.Net.Sockets.Socket class has been enhanced in Version 3.5 for use by applications that use asynchronous network I/O to achieve the highest performance. A series of new classes have been added as part of a set of enhancements to the Socket class that provide an alternative asynchronous pattern that can be used by specialized high-performance socket applications. These enhancements were specifically designed for network server applications that require high performance. An application can use the enhanced asynchronous pattern exclusively, or only in targeted hot areas of their application (when receiving large amounts of data, for example).
We're planning on ditching the current implementation for how we use NIO on Helios anyway, for a number of reasons - not the least of which is that this has been pointed out before and I agree with it.
The TL;DR; for why it is the way it is now boils down to simply not knowing any better when I wrote Helios originally. Was under an insane deadline to deliver Akka.Remote and the underlying socket implementation and our product which needed to use both in production.
The next major version I'm designing (and intending to bring to market ASAP) will address this.
After Akka.NET 1.0 ships (read: next week) I'm going to begin work on a major revamp of Helios.
Spent a lot of time in the code this week, and there's a large number of obvious areas for improvement. Learned a lot about doing socket programming since I originally wrote this nearly a year and a half ago. Looking forward to seeing what we can create together!
Looking through the code base of Helios, I was wondering why did you prefer to use APM socket abstractions in order to perform tcp communication in Helios? The traditional Begin/End async methods on high performance network applications (like Akka) can cause increased garbage collection due to memory thrashing when servers have many connections or when they are receiving large amounts of data.
The most performant communication abstractions for TCP available in .NET nowadays is EAP - XXXAsync methods (ConnectAsync, ReceiveAsync, SendAsync etc) which, when used with buffer pooling, they reduce considerably GC work and therefore increase the overall performance of the application.
https://msdn.microsoft.com/en-us/library/bb968780.aspx
The text was updated successfully, but these errors were encountered: