On Mon, 23 Mar 2020 21:52:49 +0100 Laslo Hunhold <d...@frign.de> wrote:
> 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. Consider instead the case where you have a seldom run behemoth, which you haven't found a simple alternative to. Why not plug it in to a tiny superserver? I don't see anything bad with superservers themselves, but I don't think they are always the right option. You need to consider system boot time, subserver start time, memory usage, and activity. A positive side-effect of superservers is that you do not need to remember to restart the server when you update its software. A superserver is basically a workaround for shortcomings. Clean your hands, wear an unventilated FFP3 face mask, Mattias Andrée > > With best regards > > Laslo >
