diff --git a/guides/source/tuning_performance_for_deployment.md b/guides/source/tuning_performance_for_deployment.md
index 435d5352b1d..38967a0b70f 100644
--- a/guides/source/tuning_performance_for_deployment.md
+++ b/guides/source/tuning_performance_for_deployment.md
@@ -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.