mirror of https://github.com/rails/rails
Tiny fixes to the "Tuning Performance" guide [ci skip]
Following up #51924.
This commit is contained in:
parent
ffbc964602
commit
78975c0267
|
@ -147,7 +147,7 @@ Because of how the default memory allocator works on most Linux distributions, r
|
|||
lead to an unexpected increase in memory usage caused by [memory fragmentation](https://en.wikipedia.org/wiki/Fragmentation_\(computing\)).
|
||||
In turn, this increased memory usage may prevent your application from fully utilizing the server CPU cores.
|
||||
|
||||
To alleviate this problem, it is highly recommended the configure Ruby to use an alternative memory allocator:
|
||||
To alleviate this problem, it is highly recommended to configure Ruby to use an alternative memory allocator:
|
||||
[jemalloc](https://github.com/jemalloc/jemalloc).
|
||||
|
||||
The default Dockerfile generated by Rails already comes preconfigured to install and use `jemalloc`. But if your hosting
|
||||
|
@ -261,7 +261,7 @@ It is still helpful for testing configurations.
|
|||
Your load testing program should allow you to check latencies, including percentile and tail latencies.
|
||||
|
||||
For different numbers of processes and threads, or different configurations in general, check the throughput and one or
|
||||
more latencies such as P50, P90, and P99.
|
||||
more latencies such as `P50`, `P90`, and `P99`.
|
||||
Increasing the threads will improve throughput up to a point, but worsen latency.
|
||||
|
||||
Choose a tradeoff between latency and throughput based on your application's needs.
|
||||
|
|
Loading…
Reference in New Issue