TEST_CODEOWNERS/rails
3
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Merge pull request #51976 from robin850/nitpicks-tuning-perf-guide

Browse Source 
Tiny fixes to the "Tuning Performance" guide [ci skip]
This commit is contained in:
Rafael Mendonça França 2024-05-31 17:16:38 -04:00 committed by GitHub
commit 67c7c913c6
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
guides/source/tuning_performance_for_deployment.md
View File

@ -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.