Simplify port handling and discourage listening on a port. - #3
Simplify port handling and discourage listening on a port.#3FireMasterK wants to merge 1 commit into
Conversation
| defer listener.Close() | ||
| srv.Serve(listener) | ||
| } else { | ||
| fmt.Println("WARNING: You are listening on a HTTP Socket, you are strongly recommended to use a Unix Domain Socket for performance reasons.") |
There was a problem hiding this comment.
I wouldn't say it's quite necessary to be this strong. Especially given that in many use cases, using unix sockets is impossible. To a novice user, this could be quite harmful.
There was a problem hiding this comment.
Notice or Note would be more appropriate than a warning.
There was a problem hiding this comment.
In the official guides, https://piped-docs.kavin.rocks/docs/self-hosting/#docker-compose-caddy-aio-script and https://piped-docs.kavin.rocks/docs/self-hosting/#docker-compose-with-nginx, it's always been recommended to use a Unix socket, so I don't see why this is unreasonable. Never should you run a public instance this way.
There was a problem hiding this comment.
| fmt.Println("WARNING: You are listening on a HTTP Socket, you are strongly recommended to use a Unix Domain Socket for performance reasons.") | |
| fmt.Println("Note: You are listening on a HTTP Socket. Listening on a Unix Domain Socket may increase performance.") |
There was a problem hiding this comment.
Never should you run a public instance this way.
There's a difference between running with a port, and exposing that port to the internet directly without a reverse proxy infront of it.
There was a problem hiding this comment.
There's a difference between running with a port, and exposing that port to the internet directly without a reverse proxy infront of it.
That's not the point here, even when using TCP/IP within localhost / between the reverse proxy and ytproxy, you're still wasting a significant amount of CPU resources unnecessarily.
There was a problem hiding this comment.
@FireMasterK In deployment scenarios with a service mesh (a la Istio or Consul Connect) or if one has particular reasons to keep the two processes separated - maybe they are even on different physical machines - it can be perfectly fine to prefer HTTP sockets.
Agreed that this is too strong and risks hurting more than it helps (unless there is some particular nuance specific to ytproxy I am not aware of)
4565e82 to
590b3e3
Compare
No description provided.