![]() ![]() If I round the numbers a bit, Noah's benchmark result could be said to show something like the expected speedup given by Amdahl's Law for a 25%-wait-in-I/O application (in the formula though, 25% wait-on-io translates to 25% improvement in throughput w/5 threads). These apps receive a 30 to 65% improvement (respectively) in throughput with 5 threads, w/roughly a 25% increase in memory usage. But perhaps it is better to keep Rails multi-threaded by default, so that those bugs can occur and be seen and fixed often and early? What bugs would slip through is Rails became single-thread by default I chose the default of 5 in Puma based on the benefit for a Rails app with 25-50% time spent in I/O wait (based on my experience looking at 100+ Rails apps perf dashboards, this covers 80% or more of prod apps). Of course, the second thread is the most costly thread of all: now you're multi-threaded, with all the bugs that can cause. ![]() Amdahl's Law shows that modest throughput gains can be obtained even when small parts of the program can be done in parallel - for example, a Rails application that spends 30% of it's time waiting on I/O will have 18% higher throughput with 2 threads than with 1. Noah's result accords pretty well with Amdahl's Law. It still spends 25% of its time waiting on I/O. I would certainly consider Discourse a highly-optimized Rails app, maybe one of the most highly optimized in the world. One benchmark I recall of his showed that throughput on Discourse improved 25% when going from 1 to 5 threads. Worked on this for many years (although his work stopped ~3 years ago after losing sponsorship). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |