mirror of https://github.com/apache/jmeter.git
200 lines
10 KiB
XML
200 lines
10 KiB
XML
<?xml version="1.0"?>
|
|
<!--
|
|
~ Licensed to the Apache Software Foundation (ASF) under one or more
|
|
~ contributor license agreements. See the NOTICE file distributed with
|
|
~ this work for additional information regarding copyright ownership.
|
|
~ The ASF licenses this file to you under the Apache License, Version 2.0
|
|
~ (the "License"); you may not use this file except in compliance with
|
|
~ the License. You may obtain a copy of the License at
|
|
~
|
|
~ http://www.apache.org/licenses/LICENSE-2.0
|
|
~
|
|
~ Unless required by applicable law or agreed to in writing, software
|
|
~ distributed under the License is distributed on an "AS IS" BASIS,
|
|
~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
~ See the License for the specific language governing permissions and
|
|
~ limitations under the License.
|
|
-->
|
|
|
|
<!DOCTYPE document[
|
|
<!ENTITY sect-num '17'>
|
|
<!ENTITY hellip "…" >
|
|
]>
|
|
|
|
<document prev="best-practices.html" next="component_reference.html" id="$Id$">
|
|
|
|
<properties>
|
|
<author email="dev@jmeter.apache.org">JMeter developers</author>
|
|
<title>User's Manual: My boss wants me to …</title>
|
|
</properties>
|
|
|
|
<body>
|
|
|
|
<section name="§-num;. Help! My boss wants me to load test our application!" anchor="boss">
|
|
<p>This is a fairly open-ended proposition. There are a number of questions to
|
|
be asked first, and additionally a number of resources that will be needed. You
|
|
will need some hardware to run the benchmarks/load-tests from. A number of
|
|
tools will prove useful. There are a number of products to consider. And finally,
|
|
why is Java a good choice to implement a load-testing/Benchmarking product.
|
|
</p>
|
|
<subsection name="§-num;.1 Questions to ask" anchor="questions">
|
|
<p>What is our anticipated average number of users (normal load)?
|
|
</p>
|
|
<p>What is our anticipated peak number of users?
|
|
</p>
|
|
<p>When is a good time to load-test our application (i.e. off-hours or week-ends),
|
|
bearing in mind that this may very well crash one or more of our servers?
|
|
</p>
|
|
<p>Does our application have state? If so, how does our application manage it
|
|
(cookies, session-rewriting, or some other method)?
|
|
</p>
|
|
<p>What is the testing intended to achieve?</p>
|
|
</subsection>
|
|
<subsection name="§-num;.2 Resources" anchor="resources">
|
|
<p>The following resources will prove very helpful. Bear in mind that if you
|
|
cannot locate these resources, <b>you</b> will become these resources. As you
|
|
already have your work cut out for you, it is worth knowing who the following
|
|
people are, so that you can ask them for help if you need it.
|
|
</p>
|
|
<subsection name="§-num;.2.1 Network" anchor="network">
|
|
<p>Who knows our network topology? If you run into any firewall or
|
|
proxy issues, this will become very important. As well, a private
|
|
testing network (which will therefore have very low network latency)
|
|
would be a very nice thing. Knowing who can set one up for you
|
|
(if you feel that this is necessary) will be very useful. If the
|
|
application doesn't scale as expected, who can add additional
|
|
hardware?
|
|
</p>
|
|
</subsection>
|
|
<subsection name="§-num;.2.2 Application" anchor="application">
|
|
<p>Who knows how our application functions? The normal sequence is
|
|
<ul>
|
|
<li>test (low-volume - can we benchmark our application?)</li>
|
|
<li>benchmark (the average number of users)</li>
|
|
<li>load-test (the maximum number of users)</li>
|
|
<li>test destructively (what is our hard limit?)</li>
|
|
</ul>
|
|
The <b>test</b> process may progress from black-box testing to
|
|
white-box testing (the difference is that the first requires
|
|
no knowledge of the application [it is treated as a "black box"]
|
|
while the second requires some knowledge of the application).
|
|
It is not uncommon to discover problems with the application
|
|
during this process, so be prepared to defend your work.</p>
|
|
</subsection>
|
|
</subsection>
|
|
<subsection name="§-num;.3 What platform should I use to run the benchmarks/load-tests?" anchor="platform">
|
|
<p>This should be a widely-used piece of hardware, with a standard
|
|
(i.e. vanilla) software installation. Remember, if you publish your results,
|
|
the first thing your clients will do is hire a graduate student to verify them.
|
|
You might as well make it as easy for this person as you possibly can.
|
|
</p>
|
|
<p>For Windows, Windows XP Professional should be a minimum (the others
|
|
do not multi-thread past 50-60 connections, and you probably anticipate
|
|
more users than that).
|
|
</p>
|
|
<p>Good free platforms include the linuxes, the BSDs, and Solaris Intel. If
|
|
you have a little more money, there are commercial linuxes.
|
|
This may be worth it if you need the support.
|
|
</p>
|
|
<p>
|
|
For non-Windows platforms, investigate "<code>ulimit -n unlimited</code>" with a view to
|
|
including it in your user account startup scripts (<code>.bashrc</code> or <code>.cshrc</code> scripts
|
|
for the testing account).
|
|
</p>
|
|
<p>
|
|
Also note that some Linux/Unix editions are intended for server use.
|
|
These generally have minimal or no GUI support.
|
|
Such OSes should be OK for running JMeter in CLI mode, but JMeter GUI mode probably won't work
|
|
unless you install a minimal GUI environment.
|
|
</p>
|
|
<p>As you progress to larger-scale benchmarks/load-tests, this platform
|
|
will become the limiting factor. So it's worth using the best hardware and
|
|
software that you have available. Remember to include the hardware/software
|
|
configuration in your published benchmarks.
|
|
</p>
|
|
<p><b>When you need a lot of machines or want to test the network latency, Cloud can help you.</b>
|
|
JMeter can easily be installed on Cloud instances as it runs on nearly any architecture available in the Cloud.
|
|
JMeter is also supported within Commercial Cloud PAAS if you don't want to manage it yourself.
|
|
</p>
|
|
<p>Don't forget JMeter batch (CLI) mode. This mode should be used during load testing for many reasons:
|
|
<ul>
|
|
<li>If you have a powerful server that supports Java but perhaps does not have a fast graphics implementation, or where you need to login remotely.</li>
|
|
<li>Batch (CLI) mode can reduce the network traffic compared with using a remote display or client-server mode.</li>
|
|
<li>Java AWT Thread used for GUI mode can alter injection behaviour by blocking sometimes</li>
|
|
</ul>
|
|
The batch log file can then be loaded into JMeter on a workstation for analysis, or you can
|
|
use CSV output and import the data into a spreadsheet.</p>
|
|
<note>Remember GUI mode is for Script creation and debugging, not for load testing</note>
|
|
</subsection>
|
|
<subsection name="§-num;.4 Tools" anchor="tools">
|
|
<p>The following tools will all prove useful. It is definitely worthwhile to
|
|
become familiar with them. This should include trying them out, and reading the
|
|
appropriate documentation (man-pages, info-files, application --help messages,
|
|
and any supplied documentation).
|
|
</p>
|
|
<subsection name="§-num;.4.1 ping" anchor="ping">
|
|
<p>
|
|
This can be used to establish whether or not you can reach your
|
|
target site. Options can be specified so that '<code>ping</code>' provides the
|
|
same type of route reporting as '<code>traceroute</code>'.
|
|
</p>
|
|
</subsection>
|
|
<subsection name="§-num;.4.2 nslookup/dig" anchor="dig">
|
|
<p>
|
|
While the <b>user</b> will normally use a human-readable internet
|
|
address, <b>you</b> may wish to avoid the overhead of DNS lookups when
|
|
performing benchmarking/load-testing. These can be used to determine
|
|
the unique address (dotted quad) of your target site.
|
|
</p>
|
|
</subsection>
|
|
<subsection name="§-num;.4.3 traceroute" anchor="traceroute">
|
|
<p>
|
|
If you cannot "<code>ping</code>" your target site, this may be used to determine
|
|
the problem (possibly a firewall or a proxy). It can also be used
|
|
to estimate the overall network latency (running locally should give
|
|
the lowest possible network latency - remember that your users will
|
|
be running over a possibly busy internet). Generally, the fewer hops
|
|
the better.
|
|
</p>
|
|
</subsection>
|
|
</subsection>
|
|
<subsection name="§-num;.5 How can I enhance JMeter?" anchor="plugins">
|
|
<p>There a lot of open-source and commercial providers who provide JMeter plugins or other resources for use with JMeter.
|
|
Some of these are listed on the JMeter Wiki.
|
|
They are listed under several categories:
|
|
<ul>
|
|
<li><a href="https://cwiki.apache.org/confluence/display/JMETER/JMeterPlugins">JMeterPlugins</a> - plugins for extending JMeter</li>
|
|
<li><a href="https://cwiki.apache.org/confluence/display/JMETER/JMeterAddons">JMeterAddons</a> - addons for use with JMeter, e.g. plugins for browsers, Maven and Jenkins.</li>
|
|
<li><a href="https://cwiki.apache.org/confluence/display/JMETER/JMeterServices">JMeterServices</a> - 3<sup>rd</sup> party services, e.g. cloud-based JMeter</li>
|
|
</ul>
|
|
Note that appearance of these on the Wiki does not imply any endorsement by the Apache JMeter project.
|
|
Any requests for support should be directed to the relevant supplier.
|
|
</p>
|
|
</subsection>
|
|
<subsection name="§-num;.6 Why Java?" anchor="java">
|
|
<p>Why not Perl or C?
|
|
</p>
|
|
<p>Well, Perl might be a very good choice except that the Benchmark package
|
|
seems to give fairly fuzzy results. Also, simulating multiple users with
|
|
Perl is a tricky proposition (multiple connections can be simulated by forking
|
|
many processes from a shell script, but these will not be threads, they will
|
|
be processes). However, the Perl community is very large. If you find that
|
|
someone has already written something that seems useful, this could be a very
|
|
good solution.
|
|
</p>
|
|
<p>C, of course, is a very good choice (check out the Apache <code>ab</code> tool).
|
|
But be prepared to write all of the custom networking, threading, and state
|
|
management code that you will need to benchmark your application.
|
|
</p>
|
|
<p>Java gives you (for free) the custom networking, threading, and state
|
|
management code that you will need to benchmark your application. Java is
|
|
aware of HTTP, FTP, and HTTPS - as well as RMI, IIOP, and JDBC (not to mention
|
|
cookies, URL-encoding, and URL-rewriting). In addition Java gives you automatic
|
|
garbage-collection, and byte-code level security.
|
|
</p>
|
|
</subsection>
|
|
</section>
|
|
|
|
</body>
|
|
</document>
|