PR27863: debuginfod optimization for concurrent requests
authorFrank Ch. Eigler <fche@redhat.com>
Fri, 4 Jun 2021 12:40:11 +0000 (08:40 -0400)
committerFrank Ch. Eigler <fche@redhat.com>
Wed, 9 Jun 2021 14:44:05 +0000 (10:44 -0400)
commitab38d167c40c995d4b3c3a2ac1347f9f2be9c810
tree4f42b020bccdcba2371d6d2fd4dced0590d53bed
parentc6e1f664254a8ae16e2e6d726c5159ecb7f27d3b
PR27863: debuginfod optimization for concurrent requests

Sometimes, due to configuration error, mishap, or DoS misadventure, a
debuginfod server may receive near-concurrent requests for the exact
same data from multiple clients.  In practically all cases, it is
beneficial to the clients, as well as the server, to serialize these
requests.  This way, debuginfod does not waste CPU in repeatedly &
concurrently decompressing large archives or querying upstream
servers.  Second and later requesters can benefit from the fdcache /
client-cache and get their results, probably earlier!

This patch adds an "after-you" queueing phase to servicing
http-buildid requests, whereby thereads serialize themselves on each
query URL being serviced at the moment.  Prometheus metrics are added,
and the http GET trace line is modified to print the queue+service
times separately.

Hand-tested on large kernel-debuginfo's, and shows host CPU refusing
to multiply in the face of concurrent identical queries.  The
automated test tries a hundred concurrent curls, at least some of
which are slow enough to trigger the "after-you" wait here.

Signed-off-by: Frank Ch. Eigler <fche@redhat.com>
debuginfod/ChangeLog
debuginfod/debuginfod.cxx
tests/ChangeLog
tests/run-debuginfod-find.sh