- Author: [[Http Authorization Manager]] - Full Title: Apache JMeter - User's Manual: Component Reference - Tags:: [[JMeter]] [[Java]] - URL: https://jmeter.apache.org/usermanual/component_reference.html - ### Highlights first synced by [[Readwise]] [[2020-12-10]] - **There are three different test elements used to define the samplers:** - 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. - HTTP Request - this has an implementation drop-down box, which selects the HTTP protocol implementation to be used: - **Java** - uses the HTTP implementation provided by the JVM. - This has some limitations in comparison with the HttpClient implementations - see below. - **HTTPClient4** - uses Apache HttpComponents HttpClient 4.x. - Blank Value - does not set implementation on HTTP Samplers, so relies on HTTP Request Defaults if present or on **jmeter.httpsampler** property defined in **jmeter.properties** - GraphQL HTTP Request - this is a GUI variation of the **HTTP Request** to provide more convenient UI elements to view or edit GraphQL **Query**, **Variables** and **Operation Name**, while converting them into HTTP Arguments automatically under the hood using the same sampler. This hides or customizes the following UI elements as they are less convenient for or irrelevant to GraphQL over HTTP/HTTPS requests: - **Method**: Only POST and GET methods are available conforming the GraphQL over HTTP specification. POST method is selected by default. - **Parameters** and **Post Body** tabs: you may view or edit parameter content through Query, Variables and Operation Name UI elements instead. - **File Upload** tab: irrelevant to GraphQL queries. - **Embedded Resources from HTML Files** section in the Advanced tab: irrelevant in GraphQL JSON responses. - The [[Java]] HTTP implementation has some limitations: [[Limitations of Java HTTP implementation]] - > 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. - > The API is best suited to single-threaded usage - various settings are defined via system properties, and therefore apply to all connections. - No support of Kerberos authentication - It does not support client based certificate testing with Keystore Config. - Better control of Retry mechanism - It does not support virtual hosts. - It supports only the following methods: **GET**, **POST**, **HEAD**, **OPTIONS**, **PUT**, **DELETE** and **TRACE** - Better control on DNS Caching with [DNS Cache Manager](https://jmeter.apache.org/usermanual/component_reference.html#DNS_Cache_Manager) - # Notes on this - It looks like the default implementation for the HTTP Request sampler, when no implementation is selected, is the recommended option: HTTPClient4. This is a good thing, because the Java implementation could potentially create an unbounded number of connections that may not be reused.