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
There is a new NIF-based socket backend starting with Erlang 23. It might provide some benefits such as faster / lower latency connections and allow us to inspect connection state easier as there are more options/flags we can pass to recv/send calls.
It's easy enough to experiment with it by toggling: -kernel inet_backend socket in vm.args so it can be experimented with an already existing package/release.
There are however some differences as the implementation are not 100% compatible.. It involves corner cases of how closed connects are detected, how send may block vs not-block, etc.
The idea is that it might be worth at some point switching to it as the default. Before switching to it as the default we'd have to ensure the CI passes, benchmark it, and ideally a track record someone trying it out long enough on a large enough workload sample.
An example full CI run on a variety of os/platforms we support. It seems to pass the CI test well:
(.deb packages currently fail for an unrelated reason)
The text was updated successfully, but these errors were encountered:
There is a new NIF-based socket backend starting with Erlang 23. It might provide some benefits such as faster / lower latency connections and allow us to inspect connection state easier as there are more options/flags we can pass to recv/send calls.
It's easy enough to experiment with it by toggling:
-kernel inet_backend socket
invm.args
so it can be experimented with an already existing package/release.There are however some differences as the implementation are not 100% compatible.. It involves corner cases of how closed connects are detected, how send may block vs not-block, etc.
The idea is that it might be worth at some point switching to it as the default. Before switching to it as the default we'd have to ensure the CI passes, benchmark it, and ideally a track record someone trying it out long enough on a large enough workload sample.
An example full CI run on a variety of os/platforms we support. It seems to pass the CI test well:
(.deb packages currently fail for an unrelated reason)
The text was updated successfully, but these errors were encountered: