component_reference.html

测试工具jmeter可用来进行性能测试

        
<p>
<b>
There are three versions of the sampler:
</b>

        
<ul>

        
<li>
HTTP Request - uses the default Java HTTP implementation
</li>

        
<li>
HTTP Request HTTPClient - uses Apache Commons HttpClient
</li>

        
<li>
AJP/1.3 Sampler - uses the Tomcat mod_jk protocol (allows testing of Tomcat in AJP mode without needing Apache httpd)
        The AJP Sampler does not support multiple file upload; only the first file will be used.
        
</li>

        
</ul>

         
</p>

         
<p>
The default (Java) implementation has some limitations:
</p>

         
<ul>

         
<li>
There is no control over how connections are re-used. 
         When a connection is released by JMeter, it may or may not be re-used by the same thread.
</li>

         
<li>
The API is best suited to single-threaded usage - various settings (e.g. proxy) 
         are defined via system properties, and therefore apply to all connections.
</li>

         
<li>
There is a bug in the handling of HTTPS via a Proxy (the CONNECT is not handled correctly).
         See Java bugs 6226610 and 6208335.
         
</li>

         
</ul>

         
<p>
Note: the FILE protocol is intended for testing puposes only. 
         It is handled by the same code regardless of which HTTP Sampler is used.
</p>

        
<p>
If the request requires server or proxy login authorization (i.e. where a browser would create a pop-up dialog box),
         you will also have to add an 
<a href="../usermanual/component_reference.html#HTTP_Authorization_Manager">HTTP Authorization Manager</a>
 Configuration Element.
         For normal logins (i.e. where the user enters login information in a form), you will need to work out what the form submit button does,
         and create an HTTP request with the appropriate method (usually POST) 
         and the appropriate parameters from the form definition. 
         If the page uses HTTP, you can use the JMeter Proxy to capture the login sequence.
        
</p>

        
<p>

        In versions of JMeter up to 2.2, only a single SSL context was used for all threads and samplers.
        This did not generate the proper load for multiple users.
        A separate SSL context is now used for each thread.
        To revert to the original behaviour, set the JMeter property:

<pre>

https.sessioncontext.shared=true

</pre>

        
</p>

        
<p>

        JMeter defaults to the SSL protocol level TLS.
        If the server needs a different level, e.g. SSLv3, change the JMeter property, for example:

<pre>

https.default.protocol=SSLv3

</pre>
 
        
</p>

        
<p>
If the request uses cookies, then you will also need an
        
<a href="../usermanual/component_reference.html#HTTP_Cookie_Manager">HTTP Cookie Manager</a>
.  You can
        add either of these elements to the Thread Group or the HTTP Request.  If you have
        more than one HTTP Request that needs authorizations or cookies, then add the
        elements to the Thread Group.  That way, all HTTP Request controllers will share the
        same Authorization Manager and Cookie Manager elements.
</p>


        
<p>
If the request uses a technique called "URL Rewriting" to maintain sessions,
        then see section
        
<a href="build-adv-web-test-plan.html#session_url_rewriting">
6.1 Handling User Sessions With URL Rewriting
</a>

        for additional configuration steps.
</p>


<p><b>Control Panel</b></p>
<div align="center"><img width='682' height='619' src="../../docs/images/screenshots/webtest/http-request.png"></div>
<p>
<b>Parameters</b>
<table border="1" cellspacing="0" cellpadding="2">
<tr><th>Attribute</th><th>Description</th><th>Required</th></tr>
<tr>
<td>Name</td>
<td>Descriptive name for this controller that is shown in the tree.
</td>
<td>
No
</td>
</tr>
<tr>
<td>Server</td>
<td>Domain name or IP address of the web server. e.g. www.example.com. [Do not include the http:// prefix.]
</td>
<td>
No
</td>
</tr>
<tr>
<td>Port</td>
<td>Port the web server is listening to. Default: 80
</td>
<td>
No
</td>
</tr>
<tr>
<td>Protocol</td>
<td>HTTP, HTTPS or FILE. Default: HTTP
</td>
<td>
No
</td>
</tr>
<tr>
<td>Method</td>
<td>GET, POST, HEAD, TRACE, OPTIONS, PUT, DELETE
</td>
<td>
Yes
</td>
</tr>
<tr>
<td>Content Encoding</td>
<td>Content encoding to be used (for POST and FILE)
</td>
<td>
No
</td>
</tr>
<tr>
<td>Redirect Automatically</td>
<td>
		Sets the underlying http protocol handler to automatically follow redirects,
		so they are not seen by JMeter, and thus will not appear as samples.
		Should only be used for GET and HEAD requests.
		The HttpClient sampler will reject attempts to use it for POST or PUT.
		
<b>
Warning: see below for information on cookie and header handling.
</b>

        
</td>
<td>
Yes
</td>
</tr>
<tr>
<td>Follow Redirects</td>
<td>
		This only has any effect if "Redirect Automatically" is not enabled.
		If set, the JMeter sampler will check if the response is a redirect and follow it if so.
		The redirect response will appear as an additional sample.
		Note that the HttpClient sampler may log the following message:
<br>
</br>

		"Redirect requested but followRedirects is disabled"
<br>
</br>

		This can be ignored.
		
</td>
<td>
Yes
</td>
</tr>
<tr>
<td>Use KeepAlive</td>
<td>JMeter sets the Connection: keep-alive header. This does not work properly with the default HTTP implementation, as connection re-use is not under user-control. 
                  It does work with the Jakarta httpClient implementation.
</td>
<td>
Yes
</td>
</tr>
<tr>
<td>Use multipart/form-data for HTTP POST</td>
<td>
        Use a multipart/form-data or application/x-www-form-urlencoded post request
        
</td>
<td>
Yes
</td>
</tr>
<tr>
<td>Path</td>
<td>The path to resource (for example, /servlets/myServlet). If the
resource requires query string parameters, add them below in the
"Send Parameters With the Request" section.

<b>

As a special case, if the path starts with "http://" or "https://" then this is used as the full URL.

</b>

In this case, the server, port and protocol are ignored; parameters are also ignored for GET and DELETE methods.

</td>
<td>
Yes
</td>
</tr>
<tr>
<td>Send Parameters With the Request</td>
<td>The query string will
        be generated from the list of parameters you provide.  Each parameter has a 
<i>
name
</i>
 and
        
<i>
value
</i>
, the options to encode the parameter, and an option to include or exclude an equals sign (some applications
        don't expect an equals when the value is the empty string).  The query string will be generated in the correct fashion, depending on
        the choice of "Method" you made (ie if you chose GET or DELETE, the query string will be
        appended to the URL, if POST or PUT, then it will be sent separately).  Also, if you are
        sending a file using a multipart form, the query string will be created using the
        multipart form specifications.
        
<b>
See below for some further information on parameter handling.
</b>

        
<p>

        Additionally, you can specify whether each parameter should be URL encoded.  If you are not sure what this
        means, it is probably best to select it.  If your values contain characters such as &amp; or spaces, or
        question marks, then encoding is usually required.
</p>
</td>
<td>
No
</td>
</tr>
<tr>
<td>File Path:</td>
<td>Name of the file to send.  If left blank, JMeter
        does not send a file, if filled in, JMeter automatically sends the request as
        a multipart form request.
        
<p>

        If it is a POST or PUT request and there is a single file whose 'name' attribute (below) is omitted, 
        then the file is sent as the entire body
        of the request, i.e. no wrappers are added. This allows arbitrary bodies to be sent. This functionality is present for POST requests
        after version 2.2, and also for PUT requests after version 2.3.
        
<b>
See below for some further information on parameter handling.
</b>

        
</p>

        
</td>
<td>
No
</td>
</tr>
<tr>
<td>Parameter name:</td>
<td>Value of the "name" web request parameter.
</td>
<td>
No
</td>
</tr>
<tr>
<td>MIME Type</td>
<td>MIME type (for example, text/plain).
        If it is a POST or PUT request and either the 'name' atribute (below) are omitted or the request body is
        constructed from parameter values only, then the value of this field is used as the value of the
        content-type request header.
        
</td>
<td>
No
</td>
</tr>
<tr>
<td>Retrieve All Embedded Resources from HTML Files</td>
<td>Tell JMeter to parse the HTML file
and send HTTP/HTTPS requests for all images, Java applets, JavaScript files, CSSs, etc. referenced in the file.
        See below for more details.
        
</td>
<td>
No
</td>
</tr>
<tr>
<td>Use as monitor</td>
<td>For use with the 
<a href="../usermanual/component_reference.html#Monitor_Results">Monitor Results</a>
 listener.
</td>
<td>
Yes
</td>
</tr>
<tr>
<td>Save response as MD5 hash?</td>
<td>
       If this is selected, then the response is not stored in the sample result.
       Instead, the 32 character MD5 hash of the data is calculated and stored instead.
       This is intended for testing large amounts of data.
       
</td>
<td>
Yes
</td>
</tr>
<tr>
<td>Embedded URLs must match:</td>
<td>
        If present, this must be a regular expression that is used to match against any embedded URLs found.
        So if you only want to download embedded resources from http://example.com/, use the expression:
        http://example\.com/.*
        
</td>
<td>
No
</td>
</tr>
</table>
</p>
<p>


<b>
N.B.
</b>
 when using Automatic Redirection, cookies are only sent for the initial URL.
This can cause unexpected behaviour for web-sites that redirect to a local server.
E.g. if www.example.com redirects to www.example.co.uk.
In this case the server will probably return cookies for both URLs, but JMeter will only see the cookies for the last
host, i.e. www.example.co.uk. If the next request in the test plan uses www.example.com, 
rather than www.example.co.uk, it will not get the correct cookies.
Likewise, Headers are sent for the initial request, and won't be sent for the redirect.
This is generally only a problem for manually created test plans,
as a test plan created using a recorder would continue from the redirected URL.

</p>
<p>


<b>
Parameter Handling:
</b>
<br>
</br>

For the POST and PUT method, if there is no file to send, and the name(s) of the parameter(s) are omitted,
then the body is created by concatenating all the value(s) of the parameters.
This allows arbitrary bodies to be sent.
The values are encoded if the encoding flag is set (versions of JMeter after 2.3).
See also the MIME Type above how you can control the content-type request header that is sent.

<br>
</br>

For other methods, if the name of the parameter is missing,
then the parameter is ignored. This allows the use of optional parameters defined by variables.
(versions of JMeter after 2.3)

</p>
<p>


<b>
Method Handling:
</b>
<br>
</br>

The POST and PUT request methods work similarly, except that the PUT method does not support multipart requests.
The GET and DELETE request methods work similarly.

</p>
<p>
Upto and including JMeter 2.1.1, only responses with the content-type "text/html" were scanned for
embedded resources. Other content-types were assumed to be something other than HTML.
JMeter 2.1.2 introduces the a new property 
<b>
HTTPResponse.parsers
</b>
, which is a list of parser ids,
 e.g. 
<b>
htmlParser
</b>
 and 
<b>
wmlParser
</b>
. For each id found, JMeter checks two further properties:
</p>
<ul>

 
<li>
id.types - a list of content types
</li>

 
<li>
id.className - the parser to be used to extract the embedded resources
</li>

 
</ul>
<p>
See jmeter.properties file for the details of the settings. 
 If the HTTPResponse.parser property is not set, JMeter reverts to the previous behaviour,
 i.e. only text/html responses will be scanned
</p>
<p><b>See Also:</b>
<ul>
<li><a href="test_plan.html#assertions">Assertion</a></li>
<li><a href="build-web-test-plan.html">Building a Web Test Plan</a></li>
<li><a href="build-adv-web-test-plan.html">Building an Advanced Web Test Plan</a></li>
<li><a href="../usermanual/component_reference.html#HTTP_Authorization_Manager">HTTP Authorization Manager</a>
</li>
<li><a href="../usermanual/component_reference.html#HTTP_Cookie_Manager">HTTP Cookie Manager</a>
</li>
<li><a href="../usermanual/component_reference.html#HTTP_Header_Manager">HTTP Header Manager</a>
</li>
<li><a href="../usermanual/component_reference.html#HTML_Link_Parser">HTML Link Parser</a>
</li>
<li><a href="../usermanual/component_reference.html#HTTP_Proxy_Server">HTTP Proxy Server</a>
</li>
<li><a href="../usermanual/component_reference.html#HTTP_Request_Defaults">HTTP Request Defaults</a>
</li>
<li><a href="build-adv-web-test-plan.html#session_url_rewriting">HTTP Requests and Session ID's: URL Rewriting</a></li>
</ul>
</p>
</td></tr>
<tr><td><br></td></tr>
</table>
<hr>
<table border="0" cellspacing="0" cellpadding="2">
<tr><td>
<font face="arial,helvetica,sanserif">
<h3><a name="JDBC_Request">18.1.3 JDBC Request</h3></a>
</font>
</td></tr>
<tr><td>
<p>
This sampler lets you send an JDBC Request (an SQL query) to a database.
</p>


<p>
Before using this you need to set up a

<a href="../usermanual/component_reference.html#JDBC_Connection_Configuration">JDBC Connection Configuration</a>
 Configuration element

</p>
<p><b>Control Panel</b></p>
<div align="center"><img width='449' height='335' src="../../docs/images/screenshots/jdbctest/jdbc-request.png"></div>
<p>
<b>Parameters</b>
<table border="1" cellspacing="0" cellpadding="2">
<tr><th>Attribute</th><th>Description</th><th>Required</th></tr>
<tr>
<td>Name</td>
<td>Descriptive name for this controller that is shown in the tree.
</td>