WASIX is now more performant, stable and scalable with epoll
August 8, 2023
Starting from wasmer wasmer 4.1, wasmer implements
epoll
for polling on file descriptors. This syscall was added to improve performance in wasix. However,poll_oneoff
is still supported.
The release of wasmer 4.1 introduces epoll
support for wasix.
Epoll opens up gates for scalability and improves performance in aspects such as networking, file system access, etc.
epoll
is a variant of poll
available in the Linux kernel, designed to be more efficient when dealing with large numbers of file descriptors.
Unlike poll
, which scans through all file descriptors each time it is called, epoll
uses an event-driven approach.
It maintains a watch list of file descriptors, and only those that have changed status since the last call will be returned to the user.
You can learn more about epoll
, poll
, and select
in this article by Julia Evans and this article by LIRAN B.H.
epoll
bring in for WASIX?Works on epoll
for WASIX have been underway for months and before wasmer 4.1, wasmer runtime used the poll_oneoff
syscall for non-blocking operations such as networking, file system access, etc. This meant that we had to fork mio
to use the poll_oneoff
syscall but found limitations with inconsistencies on how POSIX implements poll and how WASI specified poll_oneoff
.
Implementing the much more scalable epoll syscall allows for a consistent implementation that matches closer to POSIX without hurting WASI backward compatibility which WASIX is committed to retaining.
This means that:
epoll
scales much better when running lots of file descriptors. E.g. an http server with hundreds of connections.poll_oneoff
To sum up, the bread and butter of an HTTP Server are now more stable and scalable.
Some results from the benchmarks:
As seen above, epoll
is much more scalable than poll_oneoff
. As the number of connections increases, the performance of epoll
shines.
tokio
is the most popular asynchronous runtime for Rust. It is used by many libraries such as hyper, actix-web, tide, sqlx, async-std, etc.
Its multiplexed I/O is implemented using mio
which is a library that provides a cross-platform interface for multiplexed I/O.
mio
uses epoll
and kqueue
in its native implementation but implements poll_oneoff
for WASI.
The official notes from mio
's WASI implementation too state that:
The current implementation is somewhat limited. The
Waker
is not implemented, as at the time of writing there is no way to support wake-up a thread by callingpoll_oneoff
.
Furthermore the (re/de)register functions also don't work while concurrently polling as both registering and polling require a lock on thesubscriptions
.
FinallySelector::try_clone
, required byRegistry::try_clone
, doesn't work. However, this could be implemented by use of anArc
.
In summary, this only (barely) works using a single thread.
Why settle for single-threaded operations when you can harness the blazing power of native tokio
in WASIX?
All other libraries that depend on mio
or any other library that uses epoll
under the hood can reap the benefits of epoll
in WASIX.
So what are you waiting for? Go ahead and try out your favorite library in WASIX or start with our examples here.
Please update to wasmer 4.1.1 or above.
With the introduction of epoll
in WASIX, we have made WASIX more performant, stable, and scalable.
This is a huge step towards making apps more compatible with WASIX.
We have also added TLS support in WASIX but this deserves an article of its own. Stay tuned for more updates on WASIX.
engineeringwasmer runtimewasmerruntimeperformance
Arshia GhafooriSeptember 7, 2023
runtimeengineeringwasmer runtime
Syrus AkbaryFebruary 28, 2022