How this supposed to work in case of the command line use? Each ipa CLI call is done by a separate process so cannot do any reuse of existing TCP connection. This would only help 'ipa console' case and use of the framework's Python API, so actual benefit is not that big for a typical use (which is CLI).

You are assuming that the ipa CLI creates only one connection for each call. For some plugins it performs multiple HTTPS connections. For example ipa vault-add involves at least seven HTTPS connection.

I'm asking for details of what is going on. At the very least, I'd like to see this spelled out in the ticket.

Improving responsiveness of vault command is welcomed, but let's not forget about a bigger picture. You would need to start from the authentication first, then metadata request, then actual command execution. That would be three TCP connections already.

Some analysis is good to have.

This ticket is not about analyzing the vault, but about applying an old, simple and common technique to reduce the overhead of TCP and TLS/SSL handshake. I have used vault as an example because it is both most relevant for my work and benefits most from keep-alive. In a production env with multiple masters, all ipa CLI calls would benefit from connection keep-alive. ipa performs at least one ping to find a working framework instance. keep-alive would reduce the cost for TCP and TLS/SSL handshake at least in half.

Now to your question

• There is no authentication request involved. IPA uses preemptive authentication.
• However my setup has only one master. An actual production env would have multiple masters, so every call would be preceded by one or more ping calls to find a working master.
• The vault plugin is pretty chatty. To create and store a secret it would perform 1 (ping) + 5 (vault-add) + 8 (vault-archive) == 14 HTTP requests. A retrieve call is another 1+3 requests.

Here are some logs (noise removed) for each vault op:

$ ipa vault-add --password=12345 key
vault_add_internal/1(u'key', ipavaultsalt='...', version=u'2.215'): SUCCESS
vault_show/1(u'key', version=u'2.215'): SUCCESS
vault_show/1(u'key', version=u'2.215'): SUCCESS
vaultconfig_show/1(version=u'2.215'): SUCCESS
vault_retrieve_internal/1(u'key', session_key=...', version=u'2.215'): NotFound



$ ipa vault-archive --password=12345 --data='secret' key
vaultconfig_show/1(version=u'2.215'): SUCCESS
vault_archive_internal/1(u'key', session_key='...', nonce='...', version=u'2.215'): SUCCESS
vault_show/1(u'key', version=u'2.215'): SUCCESS
vault_show/1(u'key', version=u'2.215'): SUCCESS
vaultconfig_show/1(version=u'2.215'): SUCCESS
vault_retrieve_internal/1(u'key', session_key='...', version=u'2.215'): SUCCESS
vaultconfig_show/1(version=u'2.215'): SUCCESS
vault_archive_internal/1(u'key', session_key='...', nonce='...', version=u'2.215'): SUCCESS



$ ipa vault-retrieve --password=12345 key
vault_show/1(u'key', version=u'2.215'): SUCCESS
vaultconfig_show/1(version=u'2.215'): SUCCESS
vault_retrieve_internal/1(u'key', session_key='...', version=u'2.215'): SUCCESS

I did some experiments with python-requests. With a fast local vagrant box, 10 requests in a single session with keep-alive are about 15 to 40% faster than a TCP connection for each request. For 10 requests to a remote system (ipa.demo1.freeipa.org) keep-alive is about 3 to 4 times (!) faster. In the latter case I simple retrieve https://ipa.demo1.freeipa.org/.

master:

• 7beb6d1 Use connection keep-alive
• b2bdd2e Add debug logging for keep-alive
• 7f56728 Increase Apache HTTPD's default keep alive timeout

ipa-4-5:

• 25cf4a2 Use connection keep-alive
• f784394 Add debug logging for keep-alive
• 4b426fb Increase Apache HTTPD's default keep alive timeout

Issue linked to bug 1434384