[jmeter] 01/04: Markup changes

[fs...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

fschumacher pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/jmeter.git

commit 7d6fa9ada56dc0da8067771cde2ed9c310c3bc9f
Author: Felix Schumacher <fe...@internetallee.de>
AuthorDate: Wed Dec 30 15:02:48 2020 +0100

    Markup changes
---
 xdocs/usermanual/component_reference.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xdocs/usermanual/component_reference.xml b/xdocs/usermanual/component_reference.xml
index 870da6a..a41dc6d 100644
--- a/xdocs/usermanual/component_reference.xml
+++ b/xdocs/usermanual/component_reference.xml
@@ -5191,7 +5191,7 @@ Note that the throughput value should not be changed too often during a test
 
 <h4>Ramp-up and startup spike</h4>
 <p>You might used "ramp-up" or similar approaches to avoid a spike at the test start. For instance, if you configure <complink name="Thread Group" /> to have
-    100 threads, and set <code>Ramp-up Period</code> to 0 (or to a small number), then all the threads would start at the same time, and it would produce an unwanted spike of the load. On top of that, if you set <code>Ramp-up Period</code> too high, it might result in "too few" threads being available at the very beginning to achieve
+    100 threads, and set <code>Ramp-up Period</code> to <code>0</code> (or to a small number), then all the threads would start at the same time, and it would produce an unwanted spike of the load. On top of that, if you set <code>Ramp-up Period</code> too high, it might result in "<em>too few</em>" threads being available at the very beginning to achieve
 the required load.</p>
 <p><code>Precise Throughput Timer</code> schedules executions in a random way, so it can be used to generate constant load, and it is recommended to set both
     <code>Ramp-up Period</code> and <code>Delay</code> to <code>0</code>.</p>