The risk of collapse of what you have in place becomes important if the pre-production simulation is far from the reality of your users.
Artica offers a stress tool that reduces the risk of a degraded infrastructure and allows administrators to simulate user navigation.
The tool allows you to specify the number of users to be evaluated and the web requests that will be used for each virtual user.
This stress tool is available in community edition ( free of charge ), so you are free to use it..
It is available on Artica 4.30 Service Pack 339 or above
|
The performance of the Artica server that will perform the stress operations is not to be neglected, above 500 virtual users, it is necessary to increase the number of CPUs. Do not use the stress tool to test Artica Proxy on itself. Stress tool simulates crazy users The stress tool can be found by typing “/siege” in the address bar or in the right barr, select “Benchmarks” in the Tools section |
 |
- The Urls section allows you to add/remove urls that will be tested by your Virtual users.
- The first section “parameters” allows you to specify two important things:
- The address and port of the proxy
- and especially the field Simulate (Members) aka “Virtual Users”:
This option allows you to set the concurrent number of users.
The total number of users is technically limited to your computer's resources.
Virtual users:
The behavior is close to a real user, When the tool downloads a page, it parses it for additional page elements such as style-sheets, javascript and images.
It will make additional requests for any elements it finds.
- When clicking on the “Launch tests”, the stress tool will start to run
- A progress barr display the stress progress and you can stop it by clicking on the stop button at any time you like.
After executing the stress operation, click on reports tab
A table displays all benchmarks you have made.
- You can change the report name by clicking onj the 6th column icon.
- You can display the report results by clicking on the report name
One report shows 8 important values:
- Execution time:
specifies the duration for which each virtual user should run the benchmark.
It is not necessary to provide a duration greater than the sum of the specified attributes.
A virtual user will execute the queries in the list three times with an interval of 0.1s.
If you have 800 urls, that's 2400 requests for a total duration of 240 seconds (4 minutes).
Specifying a duration of 10 minutes for the test is therefore unnecessary.
This value is mainly used to limit the execution time (less than 4 minutes) - Transactions/Data transferred:
This number represents the total number of HTTP requests. including META redirects and elements found inside web pages.
Also The sum of data transferred to every simulated user.
It includes the header information as well as content.
Because it includes header information, the number reported by the report will be larger then the number reported by the server.
There is a hits random URLs, this number is expected to vary from run to run. - Throughput:
The average number of bytes transferred every second from the proxy to all the simulated users. - Concurrency:
This is the average number of simultaneous connections.
The metric is calculated : The sum of all transaction times divided by elapsed time (how long stress tool ran) - Availability:
This is the percentage of socket connections successfully handled by the requests.
It is the result of socket failures (including timeouts) divided by the sum of all connection attempts.
This number does not include 400 and 500 level server errors which are recorded in “Failed transactions”.
If your proxy provides ACLs and Web filtering, the tool should receive connections errors. - Elapsed time:
The duration of the entire test.
This is measured from the time the administrator invokes siege until the last simulated user completes its transactions. - Response Time:
The average time it took to respond to each simulated user's requests. - Transaction rate:
The average number of transactions the proxy was able to handle per second, in a nutshell: it is the count of all transactions divided by elapsed time.
It depends also of the availability of the remote tested web servers.
If remote web servers or bandwidth are slow, the rate will be decreased - Successful transactions / Failed transactions
The number of times the requests responded with a return code < 400 with the number of times the socket transactions failed which includes socket timeouts. - Longest transaction:
The greatest amount of time that any single transaction took, out of all transactions