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>