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).
#PROTOCOL SUPPORTED IN NEOLOAD FULL#
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.
#PROTOCOL SUPPORTED IN NEOLOAD GENERATOR#
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 kommentar(er)
