Comments on: Adding Network Analysis to a LoadRunner 9.5 Scenario http://www.shunra.com/shunrablog/index.php/2009/03/10/adding-network-analysis-to-a-loadrunner-95-scenario/ Supporting application performance management for IT professionals Tue, 07 Feb 2012 19:28:19 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: mgsbra http://www.shunra.com/shunrablog/index.php/2009/03/10/adding-network-analysis-to-a-loadrunner-95-scenario/comment-page-1/#comment-839 mgsbra Mon, 13 Sep 2010 15:26:37 +0000 http://www.shunra.com/shunrablog/?p=837#comment-839 ever yone kick mi ima try thnks ever yone kick mi ima try thnks

]]> By: Amichai Lesser http://www.shunra.com/shunrablog/index.php/2009/03/10/adding-network-analysis-to-a-loadrunner-95-scenario/comment-page-1/#comment-472 Amichai Lesser Thu, 25 Jun 2009 14:54:36 +0000 http://www.shunra.com/shunrablog/?p=837#comment-472 Hi Vijesh, 1. The delta time represents the time passed between 2 consecutive packets in the bounce diagram. The direction of the arrows are of importance here: for 2 packets coming from the client any delta time represents client rendering time/processing time, for 2 packets coming from the server the delta time represents server processing time, for 2 packets that are changing direction (app turn) the delta time represents the blocking time of the network delay. In Synchronous applications that delta time would be slightly less than or equal to the network latency (in most cases) in asynchronous applications that delta time may be very small as the participating parties are not blocked by the network delay and can keep sending messages across even if the previous message didn't complete its processing. 2. There is no ideal bandwidth usage, how much bandwidth a transaction should use is a function of many parameters but mainly it depends on the size of the data that it needs to display. There are a few guidelines though: 1. Download only what is needed for rendering (deferred loading). 2. Download only the code you need to execute the given transaction (code modulization). 3. If multiple components are needed (e.g. in a web page) download them in parallel. 4. Minify code, compress html, compress images. 3. The client network server report shows the time spent by each tier, again there is no right or wrong, however the insight that you can gain from that report includes: a. Where is the bottleneck, is this transaction server bound, client bound or too chatty and hence network bound. b. Where should the tuning efforts focus on, the client, server or messaging code. c. Will a stronger server or a stronger client improce performance (if the transaction is not server bound then a stronger server will do very little). Hope this helps, Best, Amichai Hi Vijesh,
1. The delta time represents the time passed between 2 consecutive packets in the bounce diagram. The direction of the arrows are of importance here: for 2 packets coming from the client any delta time represents client rendering time/processing time, for 2 packets coming from the server the delta time represents server processing time, for 2 packets that are changing direction (app turn) the delta time represents the blocking time of the network delay. In Synchronous applications that delta time would be slightly less than or equal to the network latency (in most cases) in asynchronous applications that delta time may be very small as the participating parties are not blocked by the network delay and can keep sending messages across even if the previous message didn’t complete its processing.
2. There is no ideal bandwidth usage, how much bandwidth a transaction should use is a function of many parameters but mainly it depends on the size of the data that it needs to display. There are a few guidelines though: 1. Download only what is needed for rendering (deferred loading). 2. Download only the code you need to execute the given transaction (code modulization). 3. If multiple components are needed (e.g. in a web page) download them in parallel. 4. Minify code, compress html, compress images.

3. The client network server report shows the time spent by each tier, again there is no right or wrong, however the insight that you can gain from that report includes:
a. Where is the bottleneck, is this transaction server bound, client bound or too chatty and hence network bound.
b. Where should the tuning efforts focus on, the client, server or messaging code.
c. Will a stronger server or a stronger client improce performance (if the transaction is not server bound then a stronger server will do very little).

Hope this helps,

Best,
Amichai

]]> By: vijesh http://www.shunra.com/shunrablog/index.php/2009/03/10/adding-network-analysis-to-a-loadrunner-95-scenario/comment-page-1/#comment-464 vijesh Mon, 15 Jun 2009 11:20:49 +0000 http://www.shunra.com/shunrablog/?p=837#comment-464 great blog !!,VE make ease the effort to pin point the network bottlenecks. i have few questions based on the reports generated by VE Reporter. 1.What is ideal value for delta time or what is the delta time value limit in an efficient/smooth network communication? 2.what should be the ideal Bandwidth usage? 3.In Client Network Server Breakdown Report, what is Ideal client;network:server time ratio? great blog !!,VE make ease the effort to pin point the network bottlenecks. i have few questions based on the reports generated by VE Reporter.

1.What is ideal value for delta time or what is the delta time value limit in an efficient/smooth network communication?
2.what should be the ideal Bandwidth usage?
3.In Client Network Server Breakdown Report, what is Ideal client;network:server time ratio?

]]>