![]() ![]() See the following high usage example due to memory: Resource UtilizationĪfter running load tests that ramped up the load over time, you’re going to see resource usage. It depends on where you think the load will hit peak capacity out, causing a bottleneck what kind of hardware will backbone your LGs. Your particular scenario might necessitate a more aggressive ramp-up (E.g., 400 VUs initially, with perhaps up to 50 VUs introduced every 30 seconds). The above also displays the addition of 10 Virtual Users every 30 seconds. Consider the following ramp-up test configuration example:Īs part of the set-up, you would start with a set number of Virtual Users (this case, 100 used), adding the number of users over time or completed iterations. In this example, if your load totaled 5,000 VU, you would plan for a minimum of 9 LGs (5,000 VU / 600 VU per LG = 8.33, or 9). If 600 VU is your mark that puts your LG at 85% of memory utilization, you can now safely and confidently identify total LG count for your full load. ![]() It could be in the ballpark of 575-600 VUs, thus establishing your planning point. For example, if your load ramps up to 700 VU while your memory is at 100% utilization, review what your load was between 80-85% memory utilization. A load of 80-85% of any specific resource limit in your test is ideal. It is not wise to run your LG’s at maximum load, hovering at the maximum limits. It is good practice to take 5-10% off of this threshold to account for a marginal safe zone (to configure the rest of your LGs’ capacity). Make a note of Virtual User load at that time, and remember its limit. Then, watch your load tests and monitor how long it takes for the LG to run its load. Best practice approach would be to create a load test using one LG/script(s) combination involved, configuring it to ramp-up at a specific rate. Once you know the hardware or Cloud Services you plan to use for load testing, you need to determine the capability of a single LG with your application and scripts. Refrain from using excessive Response Validations, avoid Kerberos authentication if possible (can stunt load capacity as it’s known to max out at 50 VU/LG), and watch out for redundant loops in transactions. It’s critical to note that script design can have an adverse impact on LG load capacity. Having Gigabit network cards (NIC) for bandwidth will alleviate LG communication and traffic bottlenecks. Having 12-16 GB of physical RAM, and allocating one-fourth to one-half heap space for the JVM is recommended. Having a Quad-core Processor (or better), rather than dual-core, is a must for heavy load testing today.
0 Comments
Leave a Reply. |