Find out how long a webcontrol / usercontrol takes for processing?

  • Thread starter Thread starter DC
  • Start date Start date
D

DC

Hi,

our cms (asp.net 2.0) dynamically inserts controls into asp.net pages,
sometimes 50 and more per page, and if we run into a performance
bottleneck we have a hard time finding out which controls cause
latencies.

We can find most of these bottlenecks by monitoring db traffic with
profiler, but we are now using an increasing amount of third party
controls which communicate with outside webservices.

We cannot insert any code into these controls and delays may not
depend of IO at all times. So my question is, can we inject something
that will give us a good figure about the control expenses? Ideally,
we would log the performance since we also see controls that usually
perform OK but become stop blocks the other moment.

TIA for any ideas,
Regards
DC
 
Have a look at the time to last byte and time to first byte from the perf
counters. That will tell you your render time. Experiment with fewer
controls and you will be able to find the balance point before performance
starts to tank. Perhaps a better option is to run WhySlow which is a plugin
on firefox, it will tell you why your web site is dog slow.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99
 
Have a look at the time to last byte and time to first byte from the perf
counters. That will tell you your render time. Experiment with fewer
controls and you will be able to find the balance point before performance
starts to tank. Perhaps a better option is to run WhySlow which is a plugin
on firefox, it will tell you why your web site is dog slow.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively onwww.lulu.com/owc$19.99
-------------------------------------------------------




Hi,
Click to expand...
our cms (asp.net 2.0) dynamically inserts controls into asp.net pages,
sometimes 50 and more per page, and if we run into a performance
bottleneck we have a hard time finding out which controls cause
latencies.
Click to expand...
We can find most of these bottlenecks by monitoring db traffic with
profiler, but we are now using an increasing amount of third party
controls which communicate with outside webservices.
Click to expand...
We cannot insert any code into these controls and delays may not
depend of IO at all times. So my question is, can we inject something
that will give us a good figure about the control expenses? Ideally,
we would log the performance since we also see controls that usually
perform OK but become stop blocks the other moment.
Click to expand...
TIA for any ideas,
Regards
DC- Zitierten Text ausblenden -
Click to expand...

- Zitierten Text anzeigen -
Click to expand...

Thank you, Alvin. We do already measure ttlb and sql performance data,
but we have to log performance on control level. We can find out which
control is causing which latency by intermittently disabling one or
the other control as you have suggested, but what I am looking for is
ongoing performance monitoring, because some of the controls with
external data connections do only cause delays at some times, and we
need to monitor this for our service levels.

Regards
DC
 
Hi,

our cms (asp.net 2.0) dynamically inserts controls into asp.net pages,
sometimes 50 and more per page, and if we run into a performance
bottleneck we have a hard time finding out which controls cause
latencies.
Click to expand...
Fifty seems like a large number of top level controls.
We can find most of these bottlenecks by monitoring db traffic with
profiler, but we are now using an increasing amount of third party
controls which communicate with outside webservices.

We cannot insert any code into these controls and delays may not
depend of IO at all times. So my question is, can we inject something
that will give us a good figure about the control expenses? Ideally,
we would log the performance since we also see controls that usually
perform OK but become stop blocks the other moment.
Click to expand...
The varying behavior of how quickly the controls' load tell me the
controls are only displaying symptoms of issues removed from the
application itself. The web service or database server are likely
where the performance issues are when a control is slow to load. The
controls are at the mercy of their external data sources.

If the problem is appearing preparing a single page instance it may
get worse. The external sources the controls require may become
swamped when tens, hundreds or thousands of page instances are created
in rapid succession.

I can only question the need for all the controls and their associated
synchronous thrash on a single page. Do the people "designing" the
page with the CMS app know anything about how ASP.NET web applications
and controls work?

regards
A.G.
 
You could probably experiment with a static method in Global.asax that uses
the Stopwatch class to handle timings and log the results either to a file
or a database. You could set up parameters such as page name, control name,
etc.
You'd invoke the method that starts the stopwatch just before loading each
control and stop it just after, which method would perform the logging.
Peter

DC said:
Have a look at the time to last byte and time to first byte from the perf
counters. That will tell you your render time. Experiment with fewer
controls and you will be able to find the balance point before
performance
starts to tank. Perhaps a better option is to run WhySlow which is a
plugin
on firefox, it will tell you why your web site is dog slow.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively onwww.lulu.com/owc$19.99
-------------------------------------------------------




Hi,
Click to expand...
our cms (asp.net 2.0) dynamically inserts controls into asp.net pages,
sometimes 50 and more per page, and if we run into a performance
bottleneck we have a hard time finding out which controls cause
latencies.
Click to expand...
We can find most of these bottlenecks by monitoring db traffic with
profiler, but we are now using an increasing amount of third party
controls which communicate with outside webservices.
Click to expand...
We cannot insert any code into these controls and delays may not
depend of IO at all times. So my question is, can we inject something
that will give us a good figure about the control expenses? Ideally,
we would log the performance since we also see controls that usually
perform OK but become stop blocks the other moment.
Click to expand...
TIA for any ideas,
Regards
DC- Zitierten Text ausblenden -
Click to expand...

- Zitierten Text anzeigen -
Click to expand...

Thank you, Alvin. We do already measure ttlb and sql performance data,
but we have to log performance on control level. We can find out which
control is causing which latency by intermittently disabling one or
the other control as you have suggested, but what I am looking for is
ongoing performance monitoring, because some of the controls with
external data connections do only cause delays at some times, and we
need to monitor this for our service levels.

Regards
DC
Click to expand...
 
You could probably experiment with a static method in Global.asax that uses
the Stopwatch class to handle timings and log the results either to a file
or a database. You could set up parameters such as page name, control name,
etc.
You'd invoke the method that starts the stopwatch just before loading each
control and stop it just after, which method would perform the logging.
Peter




Have a look at the time to last byte and time to first byte from the perf
counters. That will tell you your render time. Experiment with fewer
controls and you will be able to find the balance point before
performance
starts to tank. Perhaps a better option is to run WhySlow which is a
plugin
on firefox, it will tell you why your web site is dog slow.
--
Regards,
Alvin Bruney [MVP ASP.NET]
[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively onwww.lulu.com/owc$19.99
-------------------------------------------------------

Hi,
our cms (asp.net 2.0) dynamically inserts controls into asp.net pages,
sometimes 50 and more per page, and if we run into a performance
bottleneck we have a hard time finding out which controls cause
latencies.
We can find most of these bottlenecks by monitoring db traffic with
profiler, but we are now using an increasing amount of third party
controls which communicate with outside webservices.
We cannot insert any code into these controls and delays may not
depend of IO at all times. So my question is, can we inject something
that will give us a good figure about the control expenses? Ideally,
we would log the performance since we also see controls that usually
perform OK but become stop blocks the other moment.
TIA for any ideas,
Regards
DC- Zitierten Text ausblenden -
- Zitierten Text anzeigen -
Click to expand...
Click to expand...
Thank you, Alvin. We do already measure ttlb and sql performance data,
but we have to log performance on control level. We can find out which
control is causing which latency by intermittently disabling one or
the other control as you have suggested, but what I am looking for is
ongoing performance monitoring, because some of the controls with
external data connections do only cause delays at some times, and we
need to monitor this for our service levels.
Click to expand...
Regards
DC- Zitierten Text ausblenden -
Click to expand...

- Zitierten Text anzeigen -
Click to expand...

First of all thank you for mentioning the Stopwatch class, Peter -
because I did not know it and I always make up my own little helpers
for that.

About the global.asax: I thought there were no events before and after
control rendering, I guess we would have to log different parts of the
control lifecycle, like logging how long the Init takes, how long Load
takes (we don't know where the control designers load their data). But
this motivates me to take a closer look at global asax and trace
facilities, maybe I can get the required granularity.

Regards
DC
 
Fifty seems like a large number of top level controls.>We can find most of these bottlenecks by monitoring db traffic with


The varying behavior of how quickly the controls' load tell me the
controls are only displaying symptoms of issues removed from the
application itself. The web service or database server are likely
where the performance issues are when a control is slow to load. The
controls are at the mercy of their external data sources.

If the problem is appearing preparing a single page instance it may
get worse. The external sources the controls require may become
swamped when tens, hundreds or thousands of page instances are created
in rapid succession.

I can only question the need for all the controls and their associated
synchronous thrash on a single page. Do the people "designing" the
page with the CMS app know anything about how ASP.NET web applications
and controls work?

regards
A.G.
Click to expand...

Thank you, A.G. Your considerations about external I/O and page
production times are exaclty what we run into at times, and we want to
monitor that on a control level if possible (since different controls
on our site are designed by different contractors and we have to nail
down who is responsible for which delay).

In my opinion 50 top level controls is a medium amount, considering
that a LinkButton is a control. Actually our cms usually uses small
(and fast to produce) content controls for most of the part and only a
few more sophisticated controls (i. e. tools). But a number a 50
controls easily accumulates on a portal side (where the non-techs
require that there is enough content on one page to fill up 10
vertical screens - no matter how useless that is).

Regards
DC
 
Back
Top