Re: [dev] Superservers: Yay or Nay?

From: Laslo Hunhold <dev_AT_frign.de>
Date: Mon, 23 Mar 2020 21:52:49 +0100

On Mon, 23 Mar 2020 15:51:03 +0100
Thomas Oltmann <thomas.oltmann.hhg_AT_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
Received on Mon Mar 23 2020 - 21:52:49 CET