![]() ![]() There are other options which could increase the LG capacity. In this case, it would take 10 LG machines to run a load test for 1,500 Virtual Users (note that an LG may have an archetypal capacity for 250-5,000 VUs per machine (in some cases even more), depending on many factors). You can tell in the above that as the memory usage nears 85% (eventually near 90% and above), the load is at 155 VUs – the limit for this LG (based on existing scripts and configuration). 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. Kerberos authentication (massive memory overhead), and XPATH extractions.Storage location, complexity of design, protocols used.CPU capability and bandwidth (local hardware, and network between).Allocated heap space to the Java Virtual Machine (JVM).When figuring out LG capacity and performance, you should keep some core factors in mind: Ultimately, addressing what each of your LGs is capable of handling is the key. For example, if the internal machines you’re using for LGs have 1,000 Virtual User capacity based on current scripts and configuration, and you need to run a 10,000 VU load test, you will need 10 LG machines. Once the capacity for a single Load Generator is known, you can then extrapolate the number of total Load Generators (LG) will be needed to meet load tests demand. The following is a guide to help you understand and discover scaling your resources to meet load testing demand using NeoLoad. No manager or company wants to suffer the consequences of wasted time and budget as a result of failed testing due to unused or missing resources. As you prepare your scripts, you’re probably also thinking about Load Generator requirements – differentiation between them, their capacity and how many needed. Your Virtual User (VU) load is significantly higher than anything you’ve tested before. You’ve got complex load tests coming up with a deadline. ![]()
0 Comments
Leave a Reply. |