Given that your application is hosted in the Netherlands and your application / is worst from this location versus the other two distant (China/USA) across complex networks, the items to consider most would be local issues.

You have noted that you are using TruClient for your testing. This type of virtual user is very resource intensive on the load generators, as you are running full browser instances. As such, it is quite easy to exhaust the resource pool on your available load generators. One way you can check against this possibility is to include a control load generator in your load generator pool in the Netherlands which runs on a single virtual user. This should be running on complete independent hardware from the rest of your load generators.

If your control group and your global group (well, Netherlands based virtual users) all degrade at the same rate then you are likely looking at a network issue impacting all of the users inside of your local LAN. However, I do not think this will happen because of the apparent good throughput from the USA and CHINA during your tests.

What will most likely happen in that your control user will bounce along quite happily during the test, but your load generator with the remainder of your Truclient population (assuming one load generator here instead of three or more which would be preferred with one control generator in the group) will degrade. This is a direct sign that your load generator is bottlenecking and resulting in the slowed for your virtual users, not your application.

Always include control factors in your test design. I know that this is sort of a “scientific method 101” type discussion, but it seems that this element is oft overlooked in automated and performance test designs.

Source link


Please enter your comment!
Please enter your name here