Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The trouble with going straight to the business logic is that you can never be sure that you haven't got a problem in the presentation layer that is putting extra load on your server. And testing the business logic on its own could mean missing possible performance problems (e.g. if there are a lot of objects in a lot of HTTP sessions, your server could be spending most of its time in the garbage collector, because the heap is too low), so I would recommend creating a complex test plan that encompasses all calls to the server.</p> <p>The easiest way to achieve this is using JMeter's HTTP Proxy, fire up your browser, and let the HTTP proxy record the test plan for you.</p> <p>See <a href="http://jakarta.apache.org/jmeter/usermanual/jmeter_proxy_step_by_step.pdf" rel="nofollow">Basic JMeter Proxy Step By Step</a> on how to get started with the proxy.</p> <p>This will record all the calls made from the browser to the server (you're not interested in the javascript itself, as this happens on the browser, so won't affect the server load, though the AJAX calls will).</p> <p>The Test Plan created by the HTTP proxy will hardcode all the values, so you'll probably have to go through it to identify which values are different on each call (e.g. if you have a create option that returns a new ID, subsequent requests need to use the ID returned by the server.</p> <p>To obtain these values you can add <a href="http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Regular_Expression_Extractor" rel="nofollow">Regular Expression Extractors</a> to your requests and assign a variable name which can then be reused as a request parameter in a subsequent request. Going through the request parameters and identifying which need to be replaced by values which need to be parsed from previous pages can be a bit tedious, but is not that hard.</p> <p>For example if you're page contains a recordId in the return HTML</p> <pre><code>&lt;input type="hidden" name="recordId" value="abcqwer123" /&gt; </code></pre> <p>which needs to be used in the next request, you can use the following regex to extract it:</p> <pre><code>name="recordId"\s+value="([a-z0-9]+)" </code></pre> <p>Another thing to bear in mind is to ensure that you are using a wide range of test data (e.g. if you simulate a number of user logins, you'll want to ensure that not every test runs with the same userId, as caching may mean that heavy operations such as DB lookups are only done on your first run. In order to simplify using multiple accounts, you can use the <a href="http://jakarta.apache.org/jmeter/usermanual/component_reference.html#CSV_Data_Set_Config" rel="nofollow">CSV Data Set Config</a> to load a list of values into a variable which then changes with every iteration.</p> <p>My last advice is to look into running JMeter in <a href="http://jakarta.apache.org/jmeter/usermanual/remote-test.html" rel="nofollow">Distributed Mode</a>. This is where you start Jmeter-server on a number of remote clients that then all execute the same test. This ensures that the test clients themselves create bottlenecks by not having enough CPU cores or network bandwidth to create a large number of simultaneous requests.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload