On Mon, 23 Mar 2020 15:51:03 +0100 Thomas Oltmann <thomas.oltmann....@gmail.com> wrote:
Dear Thomas, > Hi, I hope everybody is doing well. yeah, very much. I hope you do, as well! > In the last couple of weeks I've been working on a small TCP server > application. It is intended to be used in situations where the > typical amount of requests is relatively low and traffic is > infrequent. At it's core, it's a simple fork-on-accept style server, > much like quark. Because the server will supposedly be idling for > most of the time, I thought it may be a good idea to separate the > accept() loop and the worker processes into separate executables so > that the former can be replaced by the user with a superserver like > inetd/xinetd or even systemd (because of course pid 1 has a built-in > superserver these days) to save on system resources when no traffic > is happening. However, after doing some research it seems like > superservers have pretty much fallen out of favor these days. > Also, from some back-of-the-envelope calculations I get the feeling > you won't be saving much CPU time or RAM usage this way > on modern machines anyway, but I might be wrong there. > So, what do you guys think? > Is superserver-compatibility a desirable feature for suckless > server-software? Does anybody know if they still help with reducing > resource usage (which is probably the only reason for using one)? > Is anybody here using a superserver like inetd for anything anymore? I don't think superservers really reflect the UNIX principle. Why would you want to plug in your simple HTTP-server into the behemoth that is systemd. What's wrong with quark's idle resource usage, which I think is damn low? Don't get me wrong, I'm not offended by your remarks or anything, I just cannot fathom it given other things eat up orders of magnitude more resources than an idle HTTP server. With best regards Laslo
