Highlighted
Absent Member.. Absent Member..
Absent Member..
126 views

Response time is not good

Hi everybody,

This is my first load test with performance center, and something surprise me, and before opening an issue, I would like to know your feeling.

my script has to download a PDF file from an url. To begin, I just use a web_url() to do this. I also add before and after the web_url a start and end transaction to grab the response time.
This part work as expected.

But the application was not responding all the time and sometime the response is not a complete PDF. To verify what I received, I just add 2 web_reg_find():
- one to check the beginning of the response == PDF-1.4
- other one to test the end of the response and find %%EOF

No problem, but when I lauch my script to test it on the vugen, my transaction response time was multiply by 4.

To do more tests, I made two separate test on PC servers (to have visible timming, I put logging to it's full capacity). Both script are in the attach file.
The result is that between both test, response time of the transaction is multiply by two.

I'm very surprise that the web_reg_find enter in the transaction response time, as it is only verification of the data. The response time should have end when the response is received, without the the time used to check the response.

The same question is for the time to write in log, it is also added to the transaction time.


--
david
0 Likes
6 Replies
Highlighted
Absent Member.
Absent Member.

Re: Response time is not good

Do not include any LR functions within the start and end transaction.

Have web_reg-finds before start transaction.

This should work.

Also to check if the pDF is downloaded you can check by adding
web_get_int_property(HTTP_INFO_DOWNLOAD_SIZE)

right after end transaction.
0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: Response time is not good

Hi vpathak78,

I've already tested the size, but our first version was very buggy and size was not relevant enough.

For the same transaction I have
- without web_reg_find, avg response time is 1.141s
- with web_reg_find inside the start/end transaction, avg response time is 2.696s
- with web_reg_find outside the start/end transaction, avg response time is 2.576.

All run time setting are equal, and nothing change beside the web-reg-find.


0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Response time is not good

Try wrapping up web_reg_finds within lr_timer to see the wasted time.

Also try running them more than couple of times to see if they are consistent.
0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: Response time is not good

Hi vpathak78,

I wrap the web_reg_find with a start/end timer. But as I expected, the result is 16ms, because it doesn't take the verification time, just the time to prepare the futur search.

If I wrap the web_url, it gives me a little less than the transaction duration.

So no way to know the real rtesponse time or just start transaction, web url, and end transaction, but it is a poor error handling script !

For the concistency, I only test for 25 request, but I think it is enough to validate measure, because all transaction response time are very similar !

--
david

--
david

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Response time is not good

You might be having some irritating things in the EXTRARES section of your web_url for the pdf. I have observed many times that there are links related to adobe pdf reader download that get recorded as part of EXTRARES portion of your request. Identify if your request has any unrelated things such as these and try commenting them out and execute the script again and see if it helps.

Thanks
Prashanth T
0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: Response time is not good

Hi Prashanth T,

as suggested i remove some estrares in the web_url function, even if the result is a little different, it did not resolve my trouble.

It's good to know such things, thanks.

--
david
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.