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
