Can we measure response time such that it includes complete rendering time?

[Swet]

I understand that during replay of a web-based application; requests
are sent to the server to fetch the page elements and the reponse time
includes the time from the first request sent to the server to the
last byte received. This time does not include the complete rendering
time of the web page.

In the application, I am trying to load test; I got a request to
measure the page load time which includes the complete rendering time;
so as to emulate the actual user experience.

1. I cannot use web_reg_find... as the page has graphs which take time
to load. Is there any other way to measure the complete page load time
as a end user would experience.

2. What are web page diagnostics?

Pl. help.

Thanks

[James Pulley]

Gui virtual user

--
You received this message because you are subscribed to the Google "LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com
To unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/LR-LoadRunner?hl=en

[Floris Kraak]

On Mon, Dec 28, 2009 at 1:43 PM, Swet <sweta...@gmail.com> wrote:
>
> 1. I cannot use web_reg_find... as the page has graphs which take time
> to load. Is there any other way to measure the complete page load time
> as a end user would experience.

Several, in fact. One option is a GUI virtual user, but honestly I
doubt if that is really necessary.

The key here is to realize that the rendering time of the page is
fairly constant if the system is lightly loaded; That is, your
complete rendering time is server response time plus network latency
plus rendering time in the browser. The latter won't change with more
load, normally.
So if you loadtest this application normally and then use a different
tool like HTTPWatch or a Firefox extension like YSlow, Google Page
Speed or Firebug to measure the rendering times in lightly loaded
circumstances it should be possible to extrapolate what happens with
your system when the system load increases.

Frankly, YSlow, Firebug etc. are much better tools to analyse what
causes your rendering time than GUI vusers or loadrunner. Typical case
of using the right tool for the job, imho.

Regards,
Floris
---
'What does it mean to say that one is 48% slower? That's like saying
that a squirrel is 48% juicier than an orange - maybe it's true, but
anybody who puts the two in a blender to compare them is kind of
sick.'
--- Linus Torvalds

[Swet]

Want to know if GUI virtual user means using the Web (Click & Script)
protocol with the Recording option "GUI based script" and "Record
rendering-related property values" as checked.

Also want to understand how does this option work to ensure that all
the page elements have rendered completely in the browser.

I tried the "Record rendering-related property values" option as
checked while recording my application; but it hangs and does not
record. When i uncheck this, I am able to record.

Thanks

[Floris Kraak]

On Wed, Jan 6, 2010 at 7:03 AM, Swet <sweta...@gmail.com> wrote:
>
> Want to know if GUI virtual user means using the Web (Click & Script)
> protocol with the Recording option  "GUI based script" and "Record
> rendering-related property values" as checked.

Actually I was thinking of a QTP based GUI virtual user.

> Also want to understand how does this option work to ensure that all
> the page elements have rendered completely in the browser.

I don't think it does. Or if it does, I wouldn't count on it being correct.

> I tried the "Record rendering-related property values" option as
> checked while recording my application; but it hangs and does not
> record. When i uncheck this, I am able to record.

Frankly the only way to measure rendering time correctly is to measure
it using an actual browser, not a simulation of one.
Given that fact I'd still recommend that you take a good look at tools
like HTTPWatch and Firebug.

[amit gupta]

But can any tool measure simultaneous or concurrent users more then 1 users client rendering time?? This can be measure only of  single user.

[James Pulley]

Sure, use 1000 gui users (for which you will need 1000 OS instances)

-----Original Message-----
From: amit gupta <amit....@gmail.com>
Date: Wed, 6 Jan 2010 16:49:41
To: <lr-loa...@googlegroups.com>
Subject: Re: Can we measure response time such that it includes complete
rendering time?

[Floris Kraak]

On Wed, Jan 6, 2010 at 12:19 PM, amit gupta <amit....@gmail.com> wrote:
> But can any tool measure simultaneous or concurrent users more then 1 users
> client rendering time?? This can be measure only of  single user.
>

A representative single user, yes.

You want to measure the concurrent rendering time on the client as if
there is a difference between one user rendering a webpage in their
browser and hundreds of users doing the same thing. But the point is,
there is no difference.
Every single one of those users will have their own browser to perform
the rendering. Their own OS. And most importantly, their own hardware.

There cannot be a scaling issue because rendering time on the client
by definition does not include network response time or application
response time. Once you know how much time it takes (on average, over
a number of different test runs) to render a specific page then there
is no reason at all to believe other users with a similar setup will
not see exactly the same average times for rendering the page.

Rendering time and response time are two different things. For
measuring concurrent response time, you use loadrunner. For measuring
concurrent rendering time, measuring serial rendering time is
sufficient.

[amit gupta]

so why required a client rendring time? Even I would say use stop clock to measure this. As this is completely dependend on resources of OS utilize by a person at that time.  So if your SLA says response time is 10 seconds make aware your cutomer a difference between response time and rendring time.

[jpu...@itestsolutions.com]

OK, so now you have the complete response time through ther time it takes
to render on the client. Rendering time is but one element of what takes
place on the client. If you have a lot of local javascript or other plug
in code this then represents local application processing. have you ever
seen how high CPU goes with complex Acrobat documents, through the roof!
Rendering would be on top of this. How will you decouple your rendering
from local application processing? It's a trick question, you rally can't.

Next, what machine will be your representative sample for measuring
"rendering?" The worst configured host in your enterprise whose CPU sits
at 95% because all of the background tasks installed by the client (ever
observed a browser with 15-20 toolbars?)? The pristine new host? The PC
of the person who complains the most about "How slow this %^&*&^%$#%^&*
software is!" You need to be very specific about which type of host you
are measuring from and why. Each also poses a unique set of tuning
challenges and opportunities that you may not be able to apply to other
hosts.

'Pulley

On Thu, 7 Jan 2010 01:08:01 +0530, amit gupta <amit....@gmail.com>
wrote:

LR-LoadRunne...@googlegroups.com<LR-LoadRunner%2Bunsu...@googlegroups.com>

[Swet]

Why we need to measure rendering time?
AUT is a flex based application. When we did a performance test with
100 concurrent users using LR, the avg response time was well under 5
seconds. But when we manually time it (using stopwatch), even for a
single user, the complete page rendering takes in excess of 30 seconds
sometimes more. No consistency in the response times. (goes up and
down)

Hence, the response time results from LoadRunner do not indicate
whether the AUT meets the response time requirements. (<5s)

What we now plan to do is execute the loadrunner scripts for 100
vusers and then simultaneously run a QTP script (single user) to
measure the complete rendering time using checkpoints etc....

Firebug gave some recommendations what can be done to improve the page
speed. Not sure if I can use it to time rendering etc

Any other suggestions...

Thanks

[amit gupta]

Server response time is <5 sec and rendering time 30 secs. Your application require investigation. why rendring time is so high. Can you check bandwidth and network latency between appserver and webserver?  Can you see your webserver logs and see how much time it take to load things in webserver?

 

After this check what component takes more time to load in browser. Go step by step you can able to figure out reasons.  Use

Y Slow tool it will help you in this.

--
You received this message because you are subscribed to the Google "LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com
To unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com

[Swet]

I believe the response time calculated by LoadRunner includes the
Server response time + the network latency.

> Can you check bandwidth
> and network latency between appserver and webserver?  Can you see your
> webserver logs and see how much time it take to load things in webserver?

How will this information help.

[James Pulley]

Flex, flash, acrobat performance is highly tied to workstation CPU capacity. Developers are often blessed (cursed?) with the latest multi-core processors and graphics cards so they tend not to experience the issues that you observe on the standard corporate workstation without the CPU bandwidth.

If you test on a multi core monster and find performance acceptable then this leaves you with limited options
(1) Have the developers rework the flex object with a specific corporate standard CPU capacity target
(2) Have an alternate non flex version available
(3) Upgrade hardware on slow workstations to that which will be acceptable for the enterprise
(4) Upgrade hardware for that subset of your user community which is directly responsible for the 80 percent of helpdesk call volume for complaints of slow performance. Categorize the upgrade as managements way of saying 'thank you' for all of their prior feedback on application performance.

Your use of QTP is precisely why the GUI virtual user exists

'Pulley

-----Original Message-----
From: Swet <sweta...@gmail.com>

Date: Thu, 7 Jan 2010 00:10:59
To: LoadRunner<LR-Loa...@googlegroups.com>
Subject: Re: Can we measure response time such that it includes complete
rendering time?

[chaitanya bhatt]

Actually, rendering issues should be ideally resloved during code profiling stage of the development phase of a project.

 

If the client still insists a performance tester to give statistics of rendering time of different pages/screens then it is in the book of best practices to calculate rendering time with only ONE user accessing the system(Definitely not the way you are doing: 100 Vusers + 1 QTP user. Not necessary at all). Rendering time does not get affected as the AUT gets loaded. Rendering time may vary only when measured in a different platform or hardware.

 

Regards,

Chaitanya M Bhatt

http://www.performancecompetence.com

 

--
You received this message because you are subscribed to the Google "LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com
To unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com

[karthik sivaraman]

Web Page diagnostics.. help you compare the contents of the page ( recorded / received )and check whether you have recieved all the necessary bytes.

You cannot add the rendering time to the response time as it is solely based on the web page that loads in your machine ( Internet explorer, Netscape etc ).. Load testing / Performance testing only covers the performance of the servers with the available network path... rather the performance of the client / local machine..

As long as you have response time for the graph from LR , it is good enough...to convince them that the JavaScript / Ajax takes time to load or something like that...

If they really want to take the graph rendering time, try click and script.

Best wishes,

karthik

--