Project

General

Profile

Actions

Feature #3042

closed

lighttpd on demand

Added by mackyle 5 months ago. Updated 5 months ago.

Status:
Invalid
Priority:
Low
Category:
core
Target version:
-
ASK QUESTIONS IN Forums:
No

Description

As of lighttpd 1.4.40 courtesy of issue #1584
https://redmine.lighttpd.net/issues/1584
changeset 1812f5541a1fffb720180f958cb36ae7a8fcab3d
https://redmine.lighttpd.net/projects/lighttpd/repository/14/revisions/1812f5541a1fffb720180f958cb36ae7a8fcab3d
added support for a -1 option allowing lighttpd to be run via xinetd.

For example:

    service lighttpd
    {
      type        = UNLISTED
      socket_type = stream
      protocol    = tcp
      port        = 8080
      wait        = no
      server      = /usr/sbin/lighttpd -1 -Df /etc/lighttpd/lighttpd.conf
    }

However, as mentioned in changeset 1812f5541a1fffb720180f958cb36ae7a8fcab3d,

> Note: lighttpd is designed as a high performance, long-running server,
> not a one-shot executable. This one-shot mode of operation has not been
> tuned for performance. lighttpd server start-up and initialization aims
> for correctness, not speed. If using this one-shot mode as part of fork
> and exec from xinetd, then performance is already not of high concern.

But, also since lighttpd version 1.4.40 courtesy of issue #2696
<https://redmine.lighttpd.net/issues/2696>
changeset 06b87dee346b91c36c3e7a461879f34e9900092b
https://redmine.lighttpd.net/projects/lighttpd/repository/14/revisions/06b87dee346b91c36c3e7a461879f34e9900092b
added support for a -i <secs> graceful shutdown timeout.

This is a feature request to make it possible to combine both options.

That way this xinetd configuration will become possible:

    service lighttpd
    {
      type        = UNLISTED
      socket_type = stream
      protocol    = tcp
      port        = 8080
      wait        = yes
      server      = /usr/sbin/lighttpd -i 3600 -1 -Df /etc/lighttpd/lighttpd.conf
    }

Notice the addition of "-i 3600" to the lighttpd command line and the change of the "wait" value from "no" to "yes".

When the "wait" value is "no", then xinetd goes ahead and calls `man 2 accept` on the listening socket and passes the resulting connected socket as fd 0 to lighttpd and xinetd continues to accept new connections and spawn more lighttpd processes without regard for whether or not any of the previously spawned ones have exited.

When the "wait" value is "yes", then xinetd does NOT call accept and instead passes the listening socket to the server as fd 0 and waits for the server executable to exit before it pays any attention to that listen socket again.

This feature request is for lighttpd to expect a listen socket as fd 0 instead of a connected socket if both -1 AND -i <secs> have been given as options.

With a lighttpd xinetd service configured this way, lighttpd will then start up the first time its listen port is accessed but then it will continue running and handling connections until it's been idle for 1 hour (in the case of the above example that uses "-i 3600") at which point it will gracefully exit and xinetd will start monitoring the listen socket for incoming connections again ready to start lighttpd all over again the next time its listen port is accessed.

In other words, web server on demand with none of the performance limitations of `wait = no` nor the resource implications of having a process running and idle that's not being used (on a machine with limited resources).

Note that systemd also supports both of the above xinetd configurations natively. For the "wait = yes" version you end up with a "lighttpd.socket" file that contains an "Accept=yes" line in the "[Socket]" section and an associated "lighttpd@.service" file. For the "wait = no" version you end up with a "lighttpd.socket" file that contains an "Accept=no" line in the "[Socket]" section and an associated "lighttpd.service" file.

Actions #1

Updated by gstrauss 5 months ago

  • Status changed from New to Need Feedback
  • Priority changed from Normal to Low

As with any feature request about performance, where are your performance numbers and explanation behind the requested performance parameters?

lighttpd is very fast can typically serve simple requests < 100 us for new connections and < 10 us on keep-alive connections. By comparison, lighttpd startup can be slower, some 10-20 ms, though possibly longer for more involved configurations starting up fastcgi backends. Still, serving an initial request in < 20 ms falls within the realm of reasonable, and can (much) more quickly serve subsequent keep-alive requests on the same connection.

The above initial startup time for the first request is the same whether or not "wait" is "no" or if it is "yes". If that does not meet your requirements for the first request, then using lighttpd with xinetd is probably not an acceptable solution. Instead, lighttpd is low-resource (low CPU use and low memory) and can be left as a running daemon, which is after all the way lighttpd is primarily intended to be run. Additionally, if the fastcgi or other backends are expensive in memory use or startup time, lighttpd supports adaptive backend spawning using "min-procs" => 0 since lighttpd 1.4.46. See #1162

Given the above, more justification is needed to demonstrate how the aforementioned options are insufficient and why the additional option you are proposing is better than the existing options. Details required. (Opinions will be discarded.)

Besides, you can already use lighttpd with xinetd "wait" = "yes" by having xinetd execute a shell script which dup()s stdin to fd 3, sets up systemd socket activation environment variables, and then execs lighttpd with -i <timeout> and configured with server.systemd-socket-activation = "enable"

Actions #2

Updated by gstrauss 5 months ago

  • Status changed from Need Feedback to Invalid
  • Target version deleted (1.4.x)

This feature request is for lighttpd to expect a listen socket as fd 0 instead of a connected socket if both -1 AND -i <secs> have been given as options.

No. You may not suggest breaking existing usage just because you want the combination to do something new.

In other words, web server on demand with none of the performance limitations of `wait = no` nor the resource implications of having a process running and idle that's not being used (on a machine with limited resources).

That statement is untrue. I fail to see how wait = no or wait = yes differ in any way for the initial request.

lighttpd is already available "on demand" via multiple options. To minimize memory usage, run a 32-bit lighttpd executable, do not load unneeded modules, and see min-procs in gateway server host options. Also, if not using mod_indexfile or mod_dirlisting, server.compat-module-load = "disable" and server.modules += ("mod_staticfile") will avoid loading mod_indexfile and mod_dirlisting. server.max-connections = 16 for small embedded systems reduces a memory usage a few more bytes, as long as that setting is appropriate for your small embedded system.

Try this:

lighttpd.conf
server.systemd-socket-activation = "enable"

xinetd wait = yes script to start lighttpd

#!/bin/sh
3<&0
export LISTEN_PID=$$
export LISTEN_FDS=1
exec /usr/sbin/lighttpd -i 3600 ...

Actions #3

Updated by gstrauss 5 months ago

Correction: lighttpd -1 one-shot mode up to lighttpd 1.4.56 does not support keep-alives on the same connection.

keep-alive on one-shot connections will be permitted in lighttpd 1.4.57, as long as keep-alives are not disabled in lighttpd.conf.

Actions

Also available in: Atom