This is a forward from the Supervision mailing list. The email is a
single anecdotal comparison where the s6 init system booted up slightly
faster than the systemd init system.
What's special about this is that boot speed was the original selling
point of systemd. You probably remember them saying something like "we
start everything in parallel so slow services don't hold us up.
According to the anecdote in the forwarded part of this email, systemd
boot speed is nothing special, and in fact can be outdone by a much
simpler init system.
Since then they've gone on to say that "boot speed isn't our main
benefit", but we all remember how the camel got his nose in the tent.
Enjoy this forwarded email.
SteveT
==================================================================
Begin forwarded message:
Date: Wed, 11 Aug 2021 16:35:56 +0530
From: Arjun D R <drarjun95@???>
To: Laurent Bercot <ska-supervision@???>
Cc: supervision@???
Subject: Re: S6 Queries
Thanks Laurent for the detailed explanations. We did a bootup speed
comparison between S6 and systemd. S6 is able to boot up slightly faster
than systemd. Actual result is 4-4.5% faster but we were expecting
something near to 20%.
Ours is a bit complex setup with more than 140 services (includes a lot
of long run services and a lot of dependencies). The main advantage in
systemd is, it starts many critical processes very quickly since it has
no dependency to logging services. We collect the logs from journalctl
and store it in log files. Whereas in S6, the critical services start
up is a bit delayed since it has to depend on logging services which in
turn depends on other services (responsible for backing up the previous
logs).
Arjun
On Mon, Aug 2, 2021 at 1:57 PM Laurent Bercot
<ska-supervision@???> wrote:
> >1. In systemd, the services are grouped as targets and each target
> >depends on another target as well. They start as targets. [ex:
> >Reached local-fs.target, Reached network.target, Reached UI
> >target,...]. Is there any way in S6 to start the init system based
> >on bundles?
>
> Yes, that is what bundles are for. In your stage 2 boot script
> (typically /etc/s6-linux-init/current/scripts/rc.init), you should
> invoke s6-rc as:
> s6-rc change top
> if "top" is the name of your default bundle, i.e. the bundle that
> contains all the services you want to start at boot time. You can
> basically convert the contents of your systemd targets directly into
> contents of your s6-rc bundles; and you decide which one will be
> brought up at boot time via the s6-rc invocation in your stage 2
> init script.
>
>
> >2. Are there any ways to have loosely coupling dependencies? In
> >systemd,
> we
> >have After=. After option will help the current service to start
> >after the mentioned service (in after). And the current service will
> >anyway start even if the mentioned service in After fails to start.
> >Do we have such loosely coupled dependency facility in S6?
>
> Not at the moment, no. The next version of s6-rc will allow more
> types of dependencies, with clearer semantics than the systemd ones
> (After=, Requires= and Wants= are not orthogonal, which is
> unintuitive and causes misuse); but it is still in early development.
>
> For now, s6-rc only provides one type of dependency, which is the
> equivalent of Requires+After. I realize this is not flexible enough
> for a lot of real use cases, which is one of the reasons why another
> version is in development. :)
>
>
> >3. Is there any tool available in S6 to measure the time taken by
> >each service to start? We can manually measure it from the logs, but
> >still looking for a tool which can provide accurate data.
>
> Honestly, if you use the -v2 option to your s6-rc invocation, as in
> s6-rc -v2 change top
> and you ask the catch-all logger to timestamp its lines (which should
> be the default, but you can change the timestamp style via the -t
> option to s6-linux-init-maker)
> then the difference of timestamps between the lines:
> s6-rc: info: service foo: starting
> and
> s6-rc: info: service foo successfully started
> will give you a pretty accurate measurement of the time it took
> service foo to start. These lines are written by s6-rc exactly as the
> "starting" or "completed" event occurs, and they are timestamped by
> s6-log immediately; the code path is the same for both events, so the
> delays cancel out, and the only inaccuracy left is randomness due to
> scheduling, which should not be statistically significant.
>
> At the moment, the s6-rc log is the easiest place to get this data
> from. You could probably hack something with the "time" shell command
> and s6-svwait, such as
> s6-svwait -u /run/service/foo ; time s6-svwait -U /run/service/foo
> which would give you the time it took for foo to become ready; but
> I doubt it would be any more accurate than using the timestamps in the
> s6-rc logs, and it's really not convenient to set up.
>
>
> >4. Does the S6 init system provide better boot up performance
> >compared to systemd ? One of our main motives is to attain better
> >bootup performance. Is our expectation correct?
>
> The boot up performance should be more or less *similar* to systemd.
> The code paths used by the s6 ecosystem are much shorter than the ones
> used by systemd, so _in theory_ you should get faster boots with s6.
>
> However, systemd cheats, by starting services before their
> dependencies are ready. For instance, it will start services before
> any kind of logging is ready, which is pretty dangerous for several
> reasons. As a part of its "socket activation" thing, it will also
> claim readiness on some sockets before even attempting to run the
> actual serving processes (which may fail, in which case readiness was
> a lie.) Because of that, when everything goes well, systemd cuts
> corners that s6 does not, and may gain some advantage.
>
> So all in all, I expect that depending on your system, the
> difference in speed will not be remarkable. On very simple setups
> (just a few services), systemd's overhead may be noticeable and you
> may see real improvements with s6. On complex setups with lots of
> dependencies, s6 might still have the speed advantage but I don't
> think it will be anything amazing. The real benefit of s6 is that it
> achieves roughly the same speed as systemd *while being more reliable
> and predictable*.
>
> If you actually make bootup speed comparisons between systemd and
> s6, please share them! I am interested in that kind of benchmarks, and
> I'm sure the community would like to see numbers as well.
>
> --
> Laurent
>
>
::
[DNG] Fw: S6 Queries
