HAR record¶
HAR is an abbreviation for Http Archive:
The HTTP Archive format or HAR, is a JSON-formatted archival format for logging of a web browsers interaction with a site. The common extension for these files is .har.
Several browser like Chrome or Firefox supports recording HTTP traffic as HAR natively. Most 3rd party capture proxies like Fiddler or Charles proxy also allow you to generate HAR files.
HAR recorder¶
Upon selecting the HAR option you will be prompted with a list of HAR recorders that you can use. You can check the dedicated page for the various recorders:
-
Chrome Recorder
Google Chrome has a built-in extensions which allows to easily record requests and responses and export them as HAR format.
-
Firefox Recorder
Firefox also has a built-in extensions to record HTTP archives. Use this option to import HAR in OctoPerf generated using any other WEb-browser than Google Chrome.
-
Fiddler
Fiddler is a free web-proxy which allows to capture HTTP and HTTPS requests and responses. Fiddler is very simple to use once configured. It allows to record HTTP scenarios within minutes.
-
Charles
Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet.
Note
OctoPerf can import any HAR file, if you have a different recorder, import it as if it was from Firefox.
Container generation mode¶
Automatic¶
Chrome¶
Chrome sets a page reference for every page in the HAR, this allows us to create containers that fit the application pages perfectly.
However, the dev team of Chrome made the decision to not store response contents in the HAR (except if you click them one by one in the dev tools before exporting). And because of this we do not recommend using Chrome as a recording option. You would otherwise miss the response bodies when using the debug panel to compare recording versus replays.
Others¶
Container generation will be done based on the timestamps inside the HAR file.
This means that everytime we see a gap of more than 3 seconds inside the HAR, this idle time is seen as interaction time by the user. As such this means the page is fully loaded and the next requests should be placed in a brand new container.
So as long as you pace your recording to leave 3 seconds of idle time between your clicks containers will be created to match the structure of your application. The gap is measured between the start of two consecutive requests, like the think times.
Be aware that this mode also names each container after the path of its first request, which rarely reads like a page of your application. If the names or the structure it produces do not satisfy you, we recommend using the manual mode described below.
Manual¶
using this option you can enter container names while you do the recording using any HAR recorder. We will later compare the timestamps in this timeline to the ones inside your HAR in order to create the proper structure for your virtual users.
Warning
Traffic from the HAR that is outside the timeline will not be imported. If you think your recording is incomplete, try importing the HAR again with Automatic mode to see the difference.
Click the blue arrow or hit enter to open the recorder window.
Recorder window¶
Click the + button or hit the Enter key to add a new container with the name you provided. We automatically add incremental numbers in the name field to generate a simple, ordered structure. All traffic recorded during that time will be placed under that container name when you import the HAR.
You can reset the timeline at any moment in order to start over. Be careful because reset cannot be reverted.
If you hit the Stop button we will disable all traffic recorded during that time, but it will still be imported:
You can resume recording at any time by simply entering a new container name.
Container timeline¶
Your container timeline will be kept until you import the HAR file. You can go back and forth between the last step and the container timeline if you need to edit it:
Warning
Your container timeline will be lost if you leave or refresh the page. If you want to use it, make sure to finish your HAR import before leaving OctoPerf.
Import options¶
Once your HAR file is recorded, the last step of the wizard lets you configure the import before uploading the file:
These options are the same whatever the recorder you used.
Ad blocker¶
By default OctoPerf will filter a certain number of URLs based on a few blocklists:
- https://github.com/gieljnssns/Social-media-Blocklists,
- https://www.securiteinfo.com/administration-systeme-et-reseau/outils/ultimate-hosts-blacklist.shtml
Disable Use Ad Blocker if you prefer to keep everything.
HTML resources¶
By default, Keep static resources imports every request of the HAR file, static resources included (images, JavaScript and CSS files, etc.).
Select Download resources dynamically if you want OctoPerf to remove the static resources requests. These requests will then be downloaded dynamically during runtime using the Download resources option of each request. Note that since this will extract resources from HTML hyperlinks, we only enable this option on requests that have a non-empty HTML response body.
Warning
The automatic download of resources consumes a lot of computing power, to compensate for that we will consider the virtual users as Heavy VUs.
Think times¶
Think times reproduce the pauses you made while recording, for example while reading a page or filling a form. OctoPerf computes them from the timestamps stored in the HAR file.
How think times are computed¶
The think time of a request is the time elapsed between the start of the previous request and the start of this request:
- The first request of the recording has a think time of 0 ms.
- Requests that start at the same time as the previous one, or before it, get a think time of 0 ms. This is common for the static resources that a browser loads in parallel.
- Requests served from the browser cache, WebSocket traffic and requests filtered by the ad blocker are ignored: they do not count as a previous request.
- When static resources are removed (Download resources dynamically), the pause measured before a removed resource is lost. The next request only gets the time elapsed since that resource.
For example:
| Request | Started at | Think time |
|---|---|---|
GET /home |
10:00:00.000 | 0 ms (first request) |
GET /img/logo.png |
10:00:00.150 | 150 ms |
GET /css/style.css |
10:00:00.150 | 0 ms (starts in parallel with the logo) |
POST /login |
10:00:07.400 | 7,250 ms, reduced to 5,000 ms by the default maximum |
Note
During the test, the think time of a request is a pause before that request is sent, once the previous request has completed. Since the recorded think time also contains the response time of the previous request, the replayed pause between two requests can be slightly longer than during the recording.
In automatic container generation mode, a pause of more than 3 seconds starts a new container. This pause stays on the first request of the new container, so during the test the virtual user waits at the beginning of the container, like a real user reading the previous page.
Placement¶
Placement defines where the think times are stored in the imported virtual user:
- Set on HTTP requests (default): each request keeps its own think time.
- Convert as delays between containers: all request think times are set to 0 ms. For each container, OctoPerf adds up the think times of its requests, including the pause before its first request, and inserts a Delay action with this total just before the container. No Delay action is added when the total is 0 ms.
Use Convert as delays between containers if you prefer a single pause per page, which is easier to review and edit.
The examples below come from the same recording, imported with the default maximum of 5,000 ms:
The pause made before opening the catalog page is on the first request of the container:
Each container is preceded by a Delay action. The first one adds up the short pauses between the requests of the first page:
Maximum think time¶
Max handling protects your virtual user against the long pauses of a recording, for example if you were interrupted in the middle of it:
- Cap at maximum (default): any think time higher than Max (ms) is reduced to that value. The default maximum is 5,000 ms. With Convert as delays between containers, the maximum applies to each Delay action.
- Keep original: think times are imported as recorded, however long they are.
The maximum does not change how containers are generated: a pause of more than 3 seconds still starts a new container.
Tip
Very long think times make your virtual users idle during the test. The Virtual User validation warns you about think times of 30 seconds or more.
Why a request shows 0 ms¶
After the import, a request has a think time of 0 ms when:
- it is the first request of the recording,
- it started at the same time as the previous request, or before it,
- you selected Convert as delays between containers: the pause is then on the Delay action before the container,
- you set Max (ms) to 0.
You can change any think time afterwards, request by request from the HTTP action, for many requests at once with the search and replace, or for the whole test from the user profile policies.