The current load balancing model is contingent on the race condition in Hidden Service descriptor publishing.
There's no mechanism on the edge itself to balance load, requests will simply go to whichever edge device most recently published it's descriptor to whichever dirauth the user's client contacts.
Although it's not complete yet, interim results from
MISC-17 suggest that load may not be spread across the edge quite as hoped.
Both edge devices have seen some requests, but the load has primarily been taken by one device.
Although it needs testing there's no reason to think this would be any different if one edge devices reaches saturation, which would lead to potentially serious act on delivery.
An alternative delivery model might be to have a setup like the following
- Site embed is foo.onion/something.js
- foo.onion/something.js leads to a 302 to to bar.onion/something.js or another.onion/something.js
Where a proportion of the edge would answer to bar.onion and another proportion would answer another.onion. Obviously you could use more than two descriptors if the edge were big enough. Theoretically, all edges could support all HS descriptors, but I suspect we'd then run into the same issue we're trying to work around at the moment.
The obvious issue with this, is you're introducing the time required to set up an additional circuit into the mix. So need to test what the performance impact is from a client's perspective.
If it's negligible then having some kind of mechanism where the initial point of contact (foo.onion) knows the rough load of the edge would allow it to intelligently decide which descriptor to use for the next request it received. Though spray and pray would probably also give some benefit when compared to the current model.
The initial point of contact would also need to be available on multiple edge devices to ensure it's redundant. In principle, it could be available on all edges, though there's a risk that saturation might then impact foo.onion too.
The aim of this issue is to test HTTP redirection based balancing and see what the cost of using that method is.
Activity
2016-01-17 15:50:29
2016-01-18 19:35:27
As the main aim is to gauge the impact of redirects, it's not the end of the world, but I'd have preferred to have built a model device selection mechanism to test against.
2016-01-19 07:51:32
2016-01-25 11:04:04
2016-01-25 11:17:16
Which gives us a descriptor of 52umrndqq5rf2o4v.onion
Configured in NGinx
Testing
Looks good, so just need to look at setting the test script running
2016-01-25 11:17:24
2016-01-25 11:17:39
2016-01-25 11:20:46
2016-01-25 11:21:06
2017-07-06 15:50:48
2017-07-06 15:50:48
2017-07-06 15:50:53