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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev