[tor-relays] How to reduce tor CPU load on a single bridge?

[David Fifield]

The main Snowflake bridge (https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6915AB06BFB7F)
is starting to become overloaded, because of a recent substantial
increase in users. I think the host has sufficient CPU and memory
headroom, and pluggable transport process (that receies WebSocket
connections and forwards them to tor) is scaling across multiple cores.
But the tor process is constantly using 100% of one CPU core, and I
suspect that the tor process has become a bottleneck.

Here are issues about a recent CPU upgrade on the bridge, and
observations about the proportion of CPU used by different processes:
https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/40085
https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/40086#note_2767961

I have the impression that tor cannot use more than one CPU core—is that
correct? If so, what can be done to permit a bridge to scale beyond
1×100% CPU? We can fairly easily scale the Snowflake-specific components
around the tor process, but ultimately, a tor client process expects to
connect to a bridge having a certain fingerprint, and that is the part I
don't know how to easily scale.

* Surely it's not possible to run multiple instances of tor with the
  same fingerprint? Or is it? Does the answer change if all instances
  are on the same IP address? If the OR ports are never used?
* OnionBalance does not help with this, correct?
* Are there configuration options we could set to increase parallelism?
* Is migrating to a host with better single-core performance the only
  immediate option for scaling the tor process?

Separate from the topic of scaling a single bridge, here is a past issue
with thoughts on scaling beyond one bridge. it looks as though there are
not ways to do it that do not require changes to the way tor handles its
Bridge lines.
https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/28651

* Using multiple snowflake Bridge lines does not work well, despite that
  we could arrange to have the Snowflake proxy connect the user to the
  expected bridge, because tor will try to connect to all of them, not
  choose one at random.
* Removing the fingerprint from the snowflake Bridge line in Tor Browser
  would permit the Snowflake proxies to round-robin clients over several
  bridges, but then the first hop would be unauthenticated (at the Tor
  layer). It would be nice if it were possible to specify a small set of
  permitted bridge fingerprints.