>What I
>did measure before is that on my server it takes about 1.5 seconds to establish
>the HTTPS session.
>(Keep in mind I'm calling a server a small netbook with an Atom processor and
>2GiB of RAM)
That sounds slower than it should be. My router is a 1.6 GHz Atom E620,
with 2 GiB of RAM as well, and it establishes connections in under half
a second. Is there any delay you can identify, or is it really all hot
CPU computations?
>Is that already on Alpine or does it require building? I seem to recall streaming
>is part of the latest release. Nice to know that it does it with splice. I might
>switch back to regular CGI then.
It's in the latest Alpine stable release, 3.22. It's also been in edge
for a while (I generally push new versions of my software to Alpine edge
shortly after cutting them.)
>A kTLS version of s6-tls-io is in my backlog precisely because of that.
Neat. However, be aware that s6-tls[cd]io is often used in chains of
commands: the ciphertext end could very well be two pipes, rather than a
socket; and kTLS only supports TCP sockets. For tipidee, it will work
because s6-tlsd-io's ciphertext end is indeed the socket, but there are
settings where it won't be usable (e.g. smtpd-starttls-proxy).
>As mentioned, I measured session negotiation in the same server, for a
>different use-case. For small static files it tends to be much longer than the
>transfer itself in that case, as they are in the tens of milliseconds. In the
>current case it will depend mostly in how big the blobs are I believe.
>I haven't measured this project yet.
If establishing a session uses non-negligible time compared to using
the session, then indeed you want to reuse the same connection as much
as possible, and non-NPH would be the way. Now that tipideed streams CGI
results, you should be able to use it, and as a bonus it does zero-copy.
--
Laurent
Received on Sun Jun 01 2025 - 00:50:56 CEST