Unable to trace the webrequest during loadtesting for more than 100 users
Hi,
We are unable to trace the web request (submit request) during the load testing for 100 users for our PHP application. We were able to get the same for < 100 users
During the load test , hits per second and throughput showing zero from second round in WebLOAD tool(Load testing tool) But we were not able to trace the same in DynaTrace the reason for the zero value.Have monitored the memory, CPU, Network utilization during the execution, its showing all are OK,
Please help us in letting know in troubleshooting the issue
Thanks,
Sandhya
Hi
Can you explain in more detail what you mean with "zero value"? I am not sure I understand. Where do you see that value? Or do you mean that you dont see any (=ZERO) PurePaths once you hit the 100 users in WebLoad?
Hi Andreas,
Zero Value means, the value for hits per second and throughput in the webload were showing 0(i.e throughput=0). ideally there was nothing happening in the application. We were not sure the reason for showing 0 and when we checked the same time in dynaTrace for pure path and health status of server, we did not see any errors.
the scenario was to test the web service call with 100 users to check the performance/behavior, initially it was running fine, later after 5 mins, there was no data getting populated for hits per second and throughput , Which we wanted to analyze thru dynaTrace and were unable to fine the root cause
Thanks,
Manohara KS
Okay - so - your load testing tool is actually telling you that after 5 minutes no requests are handled any more. Are there no errors? Are these requests timing out? Or are these requests coming back with HTTP 5xx?
I have the following "explanations" for this scenario
a) WebLoad is not telling you all there is to say, e.g: there are actually problems with the load generators that cant generate more load due to restrictions in your test environment. I would think that WebLoad would report these types of enviromental issues
b) All these requests are quened in a component that sits before the AppServer (thats where dynaTrace is installed). That could be a Load Balancer, Proxy or Web Server. Have you checked the performance statistics on these components? what do you see there?
I my load testing tool would tell me that Requests drop to ZERO I would first look at the details on why the load testing tool cant execute these requests. I am sure it is still trying but failing to do so. First task should be to find out what happens with these requests.
Hi,
No errors and request timeouts were observed during the execution.
a)There is no restrictions in test environment reg. load . If any , web load will definitely intimate.
b)There is no load balancer. we have monitored the webserver health during the run . Its shows Ok (CPU , Memory , network ,Disk utilization). But we need to check the health of Proxy server.
From today, We observed that during monitoring there is no network and disk utilization. Both are unavailable.
Please let us know in which cases it will happen like this.
Attached is the screenshot for your perusal.
And please let us know what is the threads, Max threads what is the threshold values how to analyze the performance metrices
It means that the agents that run on that linux box dont have the prvilidges to capture these types of metrics. Please check out the following doc page that describes what types of metrics we capture and what privilidges we need: Host Health Monitoring
Hi Andreas,
We have seen Network and Disk metrics one day back Since yesterday only , we are not getting the in the host monitoring page/dashlets.
Thanks,
Sandhya
Were the agents restarted in that timeframe? Can you have a look at the agent log files and see if there is any indication of a problem getting these counters? Last resort is also to open a support ticket
Welcome the
Dynatrace Community Forums
Check out the Forum User Guide and Forum Guidelines to learn how to get started.Community Member of the Month
August 2017
Announcing Dynatrace's Community Member of the Month for August 2017, Rick B.! Click here to read more! 