Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support listen on unix domain socket #231

Merged
merged 5 commits into from
Feb 11, 2024

Conversation

bompus
Copy link
Contributor

@bompus bompus commented Feb 10, 2024

This feature is supported by uWebSockets.js via listen_unix(), so I figured I would submit this PR to add it to hyper-express, since I need to listen on unix domain sockets for my use case.

In my environment, hyper-express listening on a tcp port achieves 27,178 req/s, but listening on the unix domain socket achieves 47,088 req/s, which surpasses both hono and elysia bun frameworks when they're also listening on a unix domain socket. I tested using both oha and autocannon, and while the specific req/s numbers were different, the % change was still there.

Part of the large performance difference for my environment might be due to my sysctl tcp configuration, but regardless, socket file communication should always be faster than tcp port, as there is less overhead.

Are you able to run some benchmarks as well in your environment to see what performance difference you see?

@kartikk221
Copy link
Owner

Hey, this looks good to merge but just had a few questions on this to ensure good implementation:

  • Is UNIX listening mainly for local machine inter process communication?
  • How are Hono, Elysia and others claiming UNIX performance as webserver performance since from what I understand UNIX sockets are for local communication only?

@kartikk221 kartikk221 merged commit 4b9977b into kartikk221:master Feb 11, 2024
@bompus
Copy link
Contributor Author

bompus commented Feb 11, 2024

As far as I know, all the web framework benchmarks are normally done while listening on a TCP port.

Unix domain sockets are only for local communication, so there is usually a web server listening on a TCP port, that then reverse proxies to the app server listening on a unix domain socket. Both nginx and caddy support this, and it's a common practice for me when both the web + app server are running locally on the same server.

In large-scale app deployments, you'd usually have dedicated web servers that reverse proxy to dedicated app servers via TCP port, so this isn't useful for that scenario. However, most web servers such as nginx and caddy don't consume very much CPU, so I usually just load balance to my web servers as combination web + app servers and haven't had any issue with that pattern.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants