Re: connection establishment versus parallel workers

On Thu, Dec 12, 2024 at 11:36 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Thu, Dec 12, 2024 at 9:43 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> > Our theory is that commit 7389aad (and follow-ups like commit 239b175) made
> > parallel worker processing much more responsive to the point of contending
> > with incoming connections, and that before this change, the kernel balanced
> > the execution of the signal handlers and ServerLoop() to prevent this.  I
> > don't have a concrete proposal yet, but I thought it was still worth
> > starting a discussion.  TBH I'm not sure we really need to do anything
> > since this arguably comes down to a trade-off between connection and worker
> > responsiveness.
>
> One factor is:
>
>          * Check if the latch is set already. If so, leave the loop
>          * immediately, avoid blocking again. We don't attempt to report any
>          * other events that might also be satisfied.

Here's an experimental patch to try changing that policy.  It improves
the connection times on my small computer with your test, but I doubt
I'm seeing the real issue.  But in theory, assuming a backlog of
connections and workers to start, I think each server loop should be
able to accept and fork one client backend, and fork up to 100
(MAX_BGWORKERS_TO_LAUNCH) background workers.