Re: [dev] Superservers: Yay or Nay?

From: Mattias Andrée <>
Date: Mon, 23 Mar 2020 22:55:55 +0100

On Mon, 23 Mar 2020 21:52:49 +0100
Laslo Hunhold <> wrote:

> On Mon, 23 Mar 2020 15:51:03 +0100
> Thomas Oltmann <> 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
Received on Mon Mar 23 2020 - 22:55:55 CET

This archive was generated by hypermail 2.3.0 : Tue Mar 24 2020 - 00:00:14 CET