6 ms·
Ruby “Thread Contention” Is Simply GVL Queuing
- taf2 2y agoIf i'm reading this correctly for web applications setting RUBY_THREAD_DEFAULT_QUANTUM_MS=10 or maybe even RUBY_THREAD_DEFAULT_QUANTUM_MS=1 could be more optimal then the current default of 100, allowing for more throughput at the cost of potentially slower single shot response times?
- masklinn 2y agoIIRC it’s complicated because it can depend on the relative run times, and how fast the IO OPs are. By lowering the quantum you’re increasing the switching overhead (because there’s more handoffs), but it might allow the io thread to complete much sooner and stop contending with the cpu thread. Python’s “new gil” (it’s some 15 years old...) uses a similar scheme, with a much lower timeout (5ms? 10?), but it still suffers from this sort of contentions, and things get worse as the number of CPU threads increase because they can hand the gil off to one another bypassing the io thread.
- jewel 2y agoI think you have that backwards; it should decrease latency and decrease throughput. I don't imagine the overhead will be too bad though, so it may decrease latency while keeping throughput essentially the same. Of course you'll want to benchmark on your specific load. For example, at my day job it'd make no difference because we don't use threads, each Passenger worker has just one thread and handles one request at a time.
- codesnik 2y agoI actually had a less than pleasant surprise when debugging sidekiq process with a higher than usual threads count, and noticing 100ms-multiples in my traces. 100ms before switch indeed seems to be too high for an app with a potential to misbehave.
- Alifatisk 2y agoI've started to use Ruby for mathematical and scientific computing using IRuby. I am not in need for high performance computing yet so Ruby is still sufficient. Oh boy what a joy it is to use.
- Toutouxc 2y agoHow I wish Ruby had been adopted as the glue-lingua franca instead of Python. I get zero joy from writing Python.
- te_chris 2y agoAgree 100%. I’ve made peace with python, accepted that I need to use it, but I hate it. Death to for loops.
- kstrauser 2y agoReally? That's one of the things I like about Python: how its for loops consistently consume an iterator, and that's it. Anything that looks like an iterator can be looped across or used in a comprehension without special casing.
- ahartmetz 2y agoI remember some Ruby tutorial that proudly showcased a 5.times begin loop_body end loop. Too cutesy IMO.
- pjmlp 2y agoPython was on the right spot as Tcl/Perl successor, Ruby only became known thanks to Rails and arrived too late for that. Already in early 2000's CERN was scripting their builds, Fortran and C++ tooling with Python. Their Grid Computing tutorials, predating what we now call Cloud, already used Python.
- masklinn 2y ago
- jeffbee 2y agoThis is what thread contention means in any language and runtime. Threads "contend" for mutexes by waiting.
- electroly 2y agoMost mutexes aren't fair; it's not strictly equivalent to queueing. That said, I agree with your larger point that I don't understand what the author finds revelatory about this.
- amw-zero 2y agoYes, but I think it's a revelation to many people that things like this map to queueing. Literally _everything_ related to performance is queueing, but we use different words for different scenarios, like "contention."
- loeg 2y ago> Literally _everything_ related to performance is queueing Well, _scaling_ is queuing. But other things: cache hit rates, data packing efficiency, efficient use of hardware intrinsics, etc, don't relate to queuing.
- amw-zero 2y agoA queue is: * An arrival rate of requests * A processing time for each request * A corresponding queue length when a new request comes in before the current one is done being processed. So anything that affects processing time affects queueing. Cache hit rates, data packing, etc., all affect processing time, but processing time is in the context of a queue.
- amw-zero 2y agoLoved this writeup, because queues are the most important and general concept in reasoning about performance. When you realize this, you start seeing them everywhere. Locks, async IO... everything is just interacting queues.
- loeg 2y agoYes, all contention is just queueing on shared resources...
- deleted 2y ago[deleted]
- mrinterweb 2y agoBen Sheldon, I really appreciate how you wrote this article. It feels like it was written in a very direct way that is more easily consumable for people who's attention tends to drift on long-form articles. I feel like you covered a complex topic succinctly, and I appreciate that. Helped me get a better understanding of thread contention. Thanks.
- leosarev 2y agoIntresting that this problem (IO-bound threads should have priority over CPU-bound threads) already solved at OS level (most OSes will give priority boost to thread that was unblocked because of end of IO operation in hope that thread will soon block with another operation).