Re: [dev] Superservers: Yay or Nay?
> 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? systemd is a notoriously bad example. I only mentioned it because it's probably the most-used superserver nowadays, thruth be told. Generally, superservers don't have to be very complicated. The original inetd is around 1000LoC if I remember correctly. FreeBSD's builtin one is 2500LoC. And I'm sure you could write a suckless one in like 500LoC if you wanted to. > 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. Well, in theory one superserver can replace lots of different idling servers, for example HTTP, SMTP, IMAP, FTP etc. So while one server alone might use less resources than the superserver, all of them combined would use quite a bit more. One way or another, I decided to go without any superserver support, as it makes the process hierarchy of my server a lot simpler. (It's already pretty complicated because of privilege separation). Best regards, Thomas
Re: [dev] Superservers: Yay or Nay?
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 >
Re: [dev] Superservers: Yay or Nay?
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. With best regards Laslo
[dev] Superservers: Yay or Nay?
Hi, I hope everybody is doing 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? Cheers, Thomas Oltmann
