> OctoPerf load testing - HTTP Servers documentation page. To configure the hostname (and authentication) of the application under load in one place.
Source: https://api.octoperf.com/doc/design/edit-virtual-user/configuration/servers/
# HTTP Action Servers
{ align=left }
The server page lets you **configure the Hostname of the application tested**. In the Virtual User tree, you can then [change the server](https://api.octoperf.com/doc/design/edit-virtual-user/action-types/http-actions/#base-url) of each HTTP Request. Having the server centralized like this allows you to quickly test different environments.
!!! warning
Servers are shared within each project, any action taken on a server can have an impact on another Virtual User.
## Server list
The server page uses a layout with the list on the left and edition on the right. The list features all the usual possibilities as described in the [dedicated section about lists](https://api.octoperf.com/doc/navigation/#lists).
On top of that, the server list has the following unique features:
- [:material-delete: Server removal](#remove-server)
- [:material-call-merge: Replace servers](#replace-servers)
- [:material-delete-off: Delete unused servers](#delete-unused)
- [:octicons-download-16: Download servers list](#download-servers)
### Remove Server
!!! warning
If a server is deleted, all associated HTTP Request Actions are also removed from their Virtual User.
As servers are commons to all VUs of a project, server removal and update may affect Virtual Users that you are not currently editing.
The goal of this feature is to easily **remove irrelevant HTTP Request Actions** from your imported VUs.
For example, when you import HAR/JMX files to create a Virtual User, many external requests may have been recorded.
Since you probably do not want to load test a third party, it is a good habit to **remove those servers that do not belong to you**.
### Replace servers
{ align=left }
The replace servers button can be used to merge several servers into a single one.
Servers selected on the left hand section will be merged into the one selected in the right hand section.
!!! note
Merged servers are not removed automatically buy you can click the [Delete Unused button](#delete-unused) to do so.
### Delete Unused
{ align=left }
This button will remove all servers that are not used in an HTTP request action.
This can be used to clean after you have created then removed several virtual users. Since servers are shared with the entire project they are not removed along with their virtual users.
### Download Servers
{ align=left }
This button downloads the list of servers as a CSV file with `protocol`, `hostname` and `port` for each server:
```
protocol,hostname,port
HTTP,petstore.octoperf.com,80
HTTPS,httpbin.org,443
```
## Update Server
For each server, you can edit:
| Name | Description |
|-----------------------------------------------------------------| --- |
| Protocol | [HTTP](http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) or [HTTPS](http://en.wikipedia.org/wiki/HTTPS) |
| Hostname | Domain name or IP address associated to the server machine |
| [Port](http://en.wikipedia.org/wiki/Port_(computer_networking)) | Usually 80 for HTTP protocol and 443 for HTTPS |
### Authorization
The Authorization table lets you specify one or more user credentials for web pages that are protected. The login/password can be provided by a [variable](https://api.octoperf.com/doc/design/edit-virtual-user/configuration/variables/) using the `${...}` syntax (e.g. `${username}`).
#### Basic authentication
[Basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) usually prompts a login dialog box upon entering the secured Path.
This setting makes OctoPerf transmits the login information when it encounters this type of page, using the required `Authorization` header and [base64](https://en.wikipedia.org/wiki/Base64) encoding.
The **Base path** represents the secured path of your server. E.g. `/` if all pages are restricted or `/path` if only what comes after this path is secured.
#### NT Lan Manager
NT LAN Manager ([NTLM](https://en.wikipedia.org/wiki/NT_LAN_Manager)) is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users.
NTLM credentials are based on data obtained during the interactive logon process and require a domain name on top of the login/password.
!!! note
NTLM sometimes requires [changing the keep alive mode](https://api.octoperf.com/doc/runtime/edit-scenario/edit-user-profile/options/device/#connection-keep-alive) to **On**. With **Auto** the last request of your script could be failing.
#### Kerberos
This authentication type requires both a domain name and a realm name.
In order to use [Kerberos](https://en.wikipedia.org/wiki/Kerberos_(protocol)) you need to upload a [jaas.conf](http://docs.oracle.com/javase/7/docs/technotes/guides/security/jgss/tutorials/LoginConfigFile.html) file and a [krb5.conf](https://msdn.microsoft.com/en-us/library/bb742433.aspx) file using the [files manager](https://api.octoperf.com/doc/design/edit-virtual-user/configuration/files/).
They will be uploaded to the proper folder of each load generator [when the test starts](https://api.octoperf.com/doc/runtime/test-startup-process/#kerberos).
Here's an example krb5.conf file:
```
[libdefaults]
default_realm = OCTOPERF.LOCAL
[realms]
OCTOPERF.LOCAL = {
kdc =
admin_server = 172.0.0.1
}
[domain_realm]
172.0.0.1= OCTOPERF.LOCAL
.172.0.0.1= OCTOPERF.LOCAL
```
!!! note
Kerberos configuration can be quite complex, you can find more a practical example in [this blog post](https://www.robin-gueldenpfennig.de/2022/05/using-kerberos-authentication-with-apache-jmeter/).
### Timeouts
| Name | Description |
| ------------------ | ------------------------------------------------------------ |
| Connection Timeout | Duration to wait for a connection to open. |
| Response Timeout | Duration to wait for a response. Note that this applies to each wait for a response. Since the server response is usually sent in several chunks, the overall elapsed time may be longer than the timeout. |
!!! note
If your response is split into several chunks, you can use a [Duration Assertion](https://octoperf.com/blog/2018/04/19/jmeter-assertions/#duration-assertion) instead of the response timeout. You can for example import this JMX and copy it into your virtual user.
### IP Spoofing
IP spoofing allows you to use multiple network interfaces to inject the load. This feature is **only usable with on-premise agents**.
**Source Address Type**
To distinguish the source address value, select the type of these:
- Select *IP/Hostname* to use a specific IP address or a (local) hostname,
- Select *Device* to pick the first available address for that interface which this may be either IPv4 or IPv6,
- Select *Device IPv4* to select the IPv4 address of the device name (like eth0, lo, em0, etc.),
- Select *Device IPv6* to select the IPv6 address of the device name (like eth0, lo, em0, etc.).
**Source Address Field**
Source IP, Hostname or Device id (Example: `192.168.0.1`, `eth0`, `wlan0` etc.).
This property is used to enable IP Spoofing. It overrides the default local IP address for this sample. The JMeter host must have multiple IP addresses (i.e. IP aliases, network interfaces, devices). The value can be a host name, IP address, or a network interface device such as `eth0` or `lo` or `wlan0`.
For more information, see [JMeter HTTP Request](http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Request) documentation related to `Source Address Type` and `Source Address Field`.
!!! warning
Load generator monitoring is disabled when using IP spoofing because JMeter containers are running in `host` networking mode.
### Usage
The Usage menu will help you visualize how by which Virtual Users your server is actually used in your project. This is a good way to anticipate which VUs will be impacted by your modifications.