Simple HTTP Builder
A quick guide for creating test with Simple HTTP Builder
Last updated
Was this helpful?
A quick guide for creating test with Simple HTTP Builder
Last updated
Was this helpful?
You can go to Create Page and choose Script Builder > Simple HTTP Builder to start creating a test.
This panel allows users to create POST, PUT, GET and DELETE requests via the web editor.
Name: It’s the name of the request to be seen in the report. It’s a mandatory field.
URL: URL or End-point of the service. It’s a mandatory field.
Response Timeout & Connect Timeout: They are not necessary for every request. They can be left blank in case unknown. In case they are set to some specific values, they will be used as an assertion for request. In case those values are reached during test execution, the request will be marked as failed.
Header Name & Header Value: They must be set according to your request. In case unknown, they can be left blank.
Body: Only available with POST and PUT type requests. You should enter the payload/message you want to send to your request in that field.
Configuration panel allows you to set the size and progression of your load test. Depending on the configuration set here, the behavior of the load will be determined. In case you want to override Loadium parameters, tick the checkbox next to each parameter to use the uploaded JMeter script’s configuration.
Total Users: Total amount of virtual users that are going to execute the script. Calculated by Engine Count * Users Per Engine
Engine Count: Amount of engines that will be used for the test execution.
Users Per Engine: This parameter lets you define the thread number to create in each load engine.
Ramp-Up Time: The amount of time that should pass (in seconds) to reach the total users, starting from 0 threads. Threads increase linearly.
🙌🏻 Example: In case you have 500 total users and 10 seconds ramp-up time, for every second, 50 threads will be generated by Loadium.
Iteration: Number of the script executions will be iterated by virtual users.
Duration: Test period (in minutes) for Loadium to execute.
Note: The test will be concluded whichever is reached first; test duration or iteration.
The test can be concluded before the iteration count is reached, due to the duration being reached. The same rule applies to vice versa. If all iterations are completed before the defined duration, the test will be concluded.
Sandbox Test: Allows you to run free tests to debug your tests. If you just want to make sure that your system is ready for testing, or your script is properly working, you can enable this option (enabling sandbox test will limit the test configuration).
Loadium allows you to run globally distributed load tests by providing servers. Lets you select regions to execute situational user simulations. When a location is chosen, engines will be generated in that particular region and all requests will come from that region.
You can find more detailed information on the Geolocation page.
GeolocationInstead of provided servers, Loadium allows you to create custom locations with Docker integration to run load tests from your personal servers.
You can find more detailed information on the Private Location page.
Private LocationDedicated IP: If the system that is going to be tested has access limitations such as a firewall or DDoS protection, you can rent static IP’s and whitelist them to allow Loadium to perform a load test on the system. Enabling this option will run the test with the rented dedicated IP’s. To rent dedicated IP’s, please contact our support.
You can find more detailed information on the Dedicated IP page.
Dedicated IPJMeter Version: Choose the JMeter version where you implemented your test scripts.
Network Type: Loadium lets you choose different network types to simulate network behavior by imitating the bandwidth and network delays. They all have different bandwidth and network delay values. In case nothing is selected, by default Wifi is set to all engines. You can find more detailed information on the Network Type page.
Network TypeLimit TPS: This parameter allows you to limit the total throughput (requests happening per second) of the test’s execution. This limitation works on engines individually, so if you are using “X” amount of engines, the maximum throughput across all engines will be limited to X * Limit Value. You can find more detailed information about TPS here.
You can find more detailed information on the TPS page.
TPSHappy testing!
If you don't see the answer to your question here, please reach out to us to let us know! We're always improving our documentation.
If you don't see the answer to your question here, please reach out to us to let us know! We're always improving our documentation.
