4 ms·
This is pretty cool. But I think an implementation that avoids the mutexes (mutices?) when allocating the backends and uses channels instead would probably per
by kitd 7y ago
This is pretty cool. But I think an implementation that avoids the mutexes (mutices?) when allocating the backends and uses channels instead would probably perform better.
2 channels needed, 1 for available backends and 1 for broken ones.
On incoming request, the front end selects an available backend from channel 1. On completion, the backend itself puts itself either back onto channel 1 on success, or channel 2 on error.
Channel 2 is periodically drained to test the previously failed backends to see if they're ready to go back onto channel 1.
- biggestdecision 7y agoChannels do not avoid mutexes, they are implemented with them under the hood.
- deleted 7y ago[deleted]
- kitd 7y agoSure, but with the above, there's 1 mutex to read the channel, not 1 per backend. And a single thread reading the channel. Plus you know that if the backend is on the channel, you know it's ready to accept, and you don't need the alive flag with synchronized access.
- biggestdecision 7y ago> there's 1 mutex to read the channel, not 1 per backend Fewer mutexes isn't necessarily an advantage, there will be far higher contention on that single mutex. Channel writes also require a lock.
- kitd 7y agoOne to read, and a single reader thread. That's no contention. One to write, that's used for writing only, not both read/write as in the published design. Edit: it's a variation on the following, but for ReverseProxies, not worker goroutines http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/ http://marcio.io/2015/07/handling-1-million-requests-per-min...
- deleted 7y ago[deleted]
- diamondo25 7y agoMutex is an abbrevation of "mutual exclusion", so afaik you cannot change the last part to " ice" due to it being an abbrevation. Mutexes.
- dullgiulio 7y agoProbably the confusion comes from the Latin word "index", whose plural is indeed "indices", although nowadays "indexes" is extremely common.
- bsaul 7y agoI've actually often read the opposite : raw mutex are usually faster than using channels (which are built over mutex).
- dullgiulio 7y agoTrue but mutex/channel is a false dichotomy: mutex serializes, channels orchestrate.
- networkimprov 7y agoThat could be a win if it makes the code clearer, but it's certainly more resource intensive. Channels appear to be magical, since they're baked into the language. But package sync APIs are generally faster.