openonload
seastar
| openonload | seastar | |
|---|---|---|
| 1 | 1 | |
| 233 | 9 | |
| - | - | |
| 10.0 | 0.0 | |
| over 1 year ago | almost 2 years ago | |
| C | C++ | |
| GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
openonload
seastar
-
Linux Kernel vs. DPDK: HTTP Performance Showdown
Hi talawahtech. Thanks for the exhaustive article.
I took a short look at the benchmark setup (https://github.com/talawahtech/seastar/blob/http-performance...), and wonder if some simplifications there lead to overinflated performance numbers. The server here executes a single read() on the connection - and as soon as it receives any data it sends back headers. A real world HTTP server needs to read data until all header and body data is consumed before responding.
Now given the benchmark probably sends tiny requests, the server might get everything in a single buffer. However every time it does not, the server will send back two responses to the server - and at that time the client will already have a response for the follow-up request before actually sending it - which overinflates numbers. Might be interesting to re-test with a proper HTTP implementation (at least read until the last 4 bytes received are \r\n\r\n, and assume the benchmark client will never send a body).
What are some alternatives?
onload - OpenOnload high performance user-level network stack
picohttpparser - tiny HTTP parser written in C (used in HTTP::Parser::XS et al.)
liburing