I made it about 16 minutes in before I figured out there is zero content in this talk. I want another downvote label due to this talk, such as “no content” or “fluff” or even “funny but totally useless”. Here’s a better talk about concurrency and maintaining systems in the cloud or on distributed systems.
As funny as it was (and I enjoyed watching it in full), I have to agree with you. It’s almost just a standup act.
Given the structure of the FoundationDB cluster, I was disappointed that they only tested Master and Co-ordinator in particular groups. What happens if both are in the minority?
Also: I followed the Jepsen blogs with some interest and note that the Riak+CRDT case (0% loss) wasn’t listed in their table.
It is there, below “Riak with strict quorum” and above Zookeper.
So it is - don’t know how I missed it.
A more recent (and highly legible) paper is “High-Performance Concurrency Control Mechanisms for Main-Memory Databases.”
Thanks for the recommendation, here’s a link to the article (PDF).
I like his proposal of a curated set of tools for encryption with a friendly UI. Even if it’s CLI.
I’d also like to see (if there’s not one already) a nice-looking site that educates on the basic concepts and best practices for sending and receiving encrypted messages securely. Something like Bitcoin’s WeUseCoins, for instance.
[Comment removed by author]
The OS can still be your bottleneck in a IO-heavy workload if you have a one thread:request model. Your maximum number of concurrent requests is going to be limited by the amount of threads that you are able to keep around at any one time. This is the thesis of the article.
The solution then is to break the one thread per request model by reaching out to libraries (or languages) that use lightweight threads/fibers. These are managed by the runtime instead of the OS and allow for about two orders of magnitude more concurrent operations than threads do.
Does anyone implement this? Its the naive base-case, practically a strawman. A pool of threads is going to be far more common […]
Yes, this is what I (and the article, I assume) was referring to. Having a thread pool does not invalidate the conclusion; even though you can reuse threads, you still have one thread of execution per OS thread, thus limiting your overall concurrency.