[tor-dev] onionbalance useful on same server / for high-spec non-location hidden servers?

[s7r]

Patrick Schleizer wrote:
> Would it be useful to run multiple Tor instances and onionbalance on the
> very same server? Or does that totally defeat the purpose of onionbalance?
> 
> In my case, it's not a location hidden service. Just an alternative way
> to connect to a server which is available over clearnet anyhow.
> 
> I guess the presumption of onionbalance is that a location hidden server
> shouldn't produce too much Tor traffic as that would be suspicious?
> 
> Is a single Tor client a bottleneck? I.e. are multiple Tor clients more
> performant than only one Tor client? Does onionbalance "only" work
> around limitations of individual servers in CPU / IO / bandwidth?
> 
> In other words, assume CPU / IO / bandwidth is "unlimited" on one
> server. (And ignore failover.) Does it make sense to run multiple Tor
> instances and onionbalance or would a single Tor instance without
> onionbalance be sufficient?
> 
> Cheers,
> Patrick

Hi Patrick,

If we don't think about the anonymity penalties (being exposed to more
Guards, more Tor traffic being observable on the network, etc.), the
biggest advantage you get by doing this is CPU related.

Because Tor is not multi-threaded, at least in my use cases, the
bottleneck was always the CPU (one core of the CPU actually better
said). If you have a single core with much Ghz, Tor will do better and
better, but this is rarely the case, most of us have less GHz spread on
more CPU cores. Because my bandwidth was always high speed, I always hit
the CPU bottleneck before saturating the bandwidth on any server.

If you run multiple Tor processes on a server, you spread the load on
multiple CPU cores, thus pushing this CPU bottleneck to higher limit. If
bandwidth is "unlimited", this should be a win.

I think this also increases the chances to also lift the next bandwidth
bottleneck, since you won't be capped at the Guard speed of one Tor
process (maybe that particular Guard is more busy or has lower speed, etc.).

Onionbalance is a must if you want all the Tor processes to respond to
the same .onion 'front' address. If you don't care to have different /
multiple hostnames, you don't need onionbalance.

Also, if anonymity is not a problem, and you know you raised your CPU
bottleneck by running multiple Tor processes, you can tune all of them
to saturate the CPU power by raising MaxClientCircuitsPending slightly
and set NumEntryGuards to a higher value like 4 or 6 and also
NumPrimaryGuards to 10x$NumEntryGuards in all the torrc's of the
processes you will run. This lifts the next bottleneck you face after
CPU: bandwidth.

However, the best way (and also most friendly for the network), if you
run a high traffic .onion where location anonymity is not a problem, is
to run a bridge Tor process that listens on localhost and uses
PublishServerDescriptor 0 in torrc, so it's not public and it's only
used by you. Then you set your Tor onion service instance to use that
bridge only. You are gonna need a bridge instance for each onion service
instance because of the CPU bottleneck will move from the onion service
instances to the bridge instance.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20200604/ec8d5de7/attachment.sig>