Report Doesnt Work
I ran load test for 2 hours. Most of the response times were in the range of milliseconds. I faced multiple issue while generating report - 1. When I generated report after the run, all data just s...
Forum Discussion
I understand the performance issue. Yeah, it makes sense that the tool's internal performance is of utmost importance to capture proper performance data for the application under load. How about having an option to enable/disable debug? In debug mode it'll log all request/response data. Yeah I understand the hard-disc, network, etc. constraints. But this mode will be very helpful for setting up the load tests. To make sure load is cycling through proper data set, it is getting expected response from app, etc. Load tests are performed by technical people. So I'm sure they'll know how to use a debug mode (provided it's mentioned in documentation to know where to find this option 
).
Also I believe in load test we expect almost all of our requests to pass. So if in debug disabled mode the tool just logs request/response for the failed ones, will it impact tool's performance much?
Regarding 'four depths' -
1. It generates reports on total response time of a test case. Wish it could be configurable to generate for request's response time.
2. This one I found very useful. But it has its own set of bugs (I've reported few of them in my other posts).
3. Havnt tried it yet, as it's not part of 1.5.0. But correct me if I misunderstood this component - This will only tell if a response time is beyond an acceptable level or such other constraints, but not for what request input it was not met. For example, if my constraint says 2 sec response time, it'll say that a response received, lets say, after 3 seconds. And it will say exactly at, for example, 1:30 PM. But it wont say what was my request data. So I cannot take the data and run it in isolation to figure out if the poor response was due to data or something else.
4. This one looks promising. Havent tried it yet. But looks like this might serve our purpose, if we can configure it to detect failures and then capture the request.
Regarding graphs -
Yes, I'm aware of the detail levels. But the issue is I can't print or save (as pdf) the entire graphs, when it's anything other than overall and spans more than the screen width. If I do, it only shows the portion that is visible on screen. For example, if I change zoom level to minutes, and print/save it, the printed/saved copy will have only half an hour worth graph.
I'm guessing this might have something to do with paper width. But I suppose the solution would be to generate the graphs in multiple segments.
I know I have made several threads about LoadUI. So dont get me wrong. I like this tool, a lot. But I think it has room for improvement and currently few bugs are making things a little difficult. So to get those fixed and to see this tool become robust I put my suggestions/concerns.
).Also I believe in load test we expect almost all of our requests to pass. So if in debug disabled mode the tool just logs request/response for the failed ones, will it impact tool's performance much?
Regarding 'four depths' -
1. It generates reports on total response time of a test case. Wish it could be configurable to generate for request's response time.
2. This one I found very useful. But it has its own set of bugs (I've reported few of them in my other posts).
3. Havnt tried it yet, as it's not part of 1.5.0. But correct me if I misunderstood this component - This will only tell if a response time is beyond an acceptable level or such other constraints, but not for what request input it was not met. For example, if my constraint says 2 sec response time, it'll say that a response received, lets say, after 3 seconds. And it will say exactly at, for example, 1:30 PM. But it wont say what was my request data. So I cannot take the data and run it in isolation to figure out if the poor response was due to data or something else.
4. This one looks promising. Havent tried it yet. But looks like this might serve our purpose, if we can configure it to detect failures and then capture the request.
Regarding graphs -
Yes, I'm aware of the detail levels. But the issue is I can't print or save (as pdf) the entire graphs, when it's anything other than overall and spans more than the screen width. If I do, it only shows the portion that is visible on screen. For example, if I change zoom level to minutes, and print/save it, the printed/saved copy will have only half an hour worth graph.
I'm guessing this might have something to do with paper width. But I suppose the solution would be to generate the graphs in multiple segments.
I know I have made several threads about LoadUI. So dont get me wrong. I like this tool, a lot. But I think it has room for improvement and currently few bugs are making things a little difficult. So to get those fixed and to see this tool become robust I put my suggestions/concerns.
