-
Notifications
You must be signed in to change notification settings - Fork 664
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make Ruby use all CPU cores (via Puma workers) #193
Make Ruby use all CPU cores (via Puma workers) #193
Conversation
Whooo this is SO much nicer! Merge it I say! :-D ╰─➤ tools/stats.exs -w 1 -d 3 _ Processing servers:
Processing: bin/server_cpp_evhtp
RankingsRanking by Average Requests per second:
|
Hi @AlexWayfer, Thanks for your I have a question however, why using the number of cores to determine worker numbers ? I have always used about 2 workers on each cores. `nproc`*2+1 | bc -l Regards, |
There is the source: #190 (comment)
Any argumentation of this? |
At least in the C++/Nim/Go/Rust tests I did going higher than core count slowed them down, but if the Ruby implementations are waiting on sockets often then it might help to increase them, however if they are mostly not waiting then it won't help. Let me test this, hold on... |
Puma isn't dying properly! Ack! Above records might be inaccurate... Why can't ruby-stuff follow proper unix process styles... >.< Brutally killing all puma on Either way on a 16-core system: 1. 5626 req/sec : bin/server_ruby_roda
2. 11740 req/sec : bin/server_ruby_roda
4. 34670 req/sec : bin/server_ruby_roda
8. 58687 req/sec : bin/server_ruby_roda
16. 84807 req/sec : bin/server_ruby_roda
24. 83468 req/sec : bin/server_ruby_roda
32. 79125 req/sec : bin/server_ruby_roda So yeah, going higher than the core count gets slower as expected on anything that is waiting on code instead of events. I really wish all of the servers took an argument to set their thread/worker count so they could be properly tested from the benchmarker too... >.> |
And here's the results with puma being brutally killed (apparently when started as a 'cluster' it's processes are named different...): ╰─➤ tools/stats.exs -w 1 -d 3 _ Processing servers:
Processing: bin/server_cpp_evhtp
RankingsRanking by Average Requests per second:
|
I didn't understand what problems you have with Puma (benchmark tool should kill all |
Similar yeah. The issue with the unix bit is that a program should either be a daemon ( |
How to make something like: I'm not sure that |
@AlexWayfer sure it works, but I'm not sure about number of core to use or could even create a Etc.nprocessors |
@waghanza, I don't understand what's happening:
Then 6 processes (threads?):
After 10 seconds (still
|
It specifies the workers, but maybe each worker has IO threads. IO threads is a common strategy in older style frameworks to poll the IO so I'd almost bet that is what it is, which if it is then that's perfectly okay. |
@AlexWayfer I will see, but |
Rack is interface between web-servers (like Puma) and frameworks (like Flame). |
@AlexWayfer but |
@AlexWayfer I do not understand the ouput of |
f90cc24
to
e18856e
Compare
Oh, it looks good. Thank you, @waghanza. Is it ready to merge or something else is needed? Also I thought about symbolic links of common files (as |
This is mergeable @AlexWayfer I thought about some templating for |
Related to #69
It starts many workers for each framework, I tested.
/cc @OvermindDL1