By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,045 Members | 1,308 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,045 IT Pros & Developers. It's quick & easy.

Trace overhead

P: n/a
Does anyone know what kind of overhead is caused by enabling tracing in an
ASP.NET 1.1 app?

On my production servers I'd like to leave it enabled so I can view
trace.axd to get a feel for the activity and problems on my site, I'd leave
pageOutput="false". But I'm wondering what kind of extra load my servers
experience due to this. Any ideas?

I'm also curious how bumping up the requestLimit increases the overhead?
I'd like to use a value of 250 or more.

I haven't found any documentation on the overhead associated with tracing.

-Brett-
Nov 18 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
The performance hit is considerable, but it won't render the app unusable.
In fact, if your server fully loaded, I doubt the users would even notice.
I've done performance testing with and without tracing, and tracing cuts my
requests/sec in half, but my normal usage is way lower than my stress
testing usage, so I wouldn't worry. Because you are considering tracing in
production, I'm assuming that this isn't a "if the site is slow, we lose $5
billion" application. After your 250 request threshold is reached, the
performance will increase again because tracing will be turned off.

Jeffrey Palermo

"Brett Robichaud" <br************@nospam.yahoo.com> wrote in message
news:e2**************@TK2MSFTNGP11.phx.gbl...
Does anyone know what kind of overhead is caused by enabling tracing in an
ASP.NET 1.1 app?

On my production servers I'd like to leave it enabled so I can view
trace.axd to get a feel for the activity and problems on my site, I'd leave pageOutput="false". But I'm wondering what kind of extra load my servers
experience due to this. Any ideas?

I'm also curious how bumping up the requestLimit increases the overhead?
I'd like to use a value of 250 or more.

I haven't found any documentation on the overhead associated with tracing.

-Brett-

Nov 18 '05 #2

P: n/a
Performance on our site is definitely not the top concern, just the standard
'it should be reasonably fast'.

Thanks for the insight on your own performance testing.

I'm curious about your last comment. It was my understanding that the trace
request threshold was a rolling FIFO cache. You state that after 250
requests (assuming I set the limit at 250) it would stop tracing. Is this
true? I assumed it would just throw the top requests off the cache and keep
tracing. If what you're saying is true then the usefulness of it for me is
significantly reduced.

-Brett-

"Jeffrey Palermo" <je************@yahoo.com> wrote in message
news:eb**************@TK2MSFTNGP10.phx.gbl...
The performance hit is considerable, but it won't render the app unusable.
In fact, if your server fully loaded, I doubt the users would even notice.
I've done performance testing with and without tracing, and tracing cuts my requests/sec in half, but my normal usage is way lower than my stress
testing usage, so I wouldn't worry. Because you are considering tracing in production, I'm assuming that this isn't a "if the site is slow, we lose $5 billion" application. After your 250 request threshold is reached, the
performance will increase again because tracing will be turned off.

Jeffrey Palermo

"Brett Robichaud" <br************@nospam.yahoo.com> wrote in message
news:e2**************@TK2MSFTNGP11.phx.gbl...
Does anyone know what kind of overhead is caused by enabling tracing in an ASP.NET 1.1 app?

On my production servers I'd like to leave it enabled so I can view
trace.axd to get a feel for the activity and problems on my site, I'd

leave
pageOutput="false". But I'm wondering what kind of extra load my servers experience due to this. Any ideas?

I'm also curious how bumping up the requestLimit increases the overhead?
I'd like to use a value of 250 or more.

I haven't found any documentation on the overhead associated with tracing.
-Brett-


Nov 18 '05 #3

P: n/a
Yes, your fears are true. Test it out for yourself. Set the trace limit to
2, then hit your app. Only the first 2 requests will show up on trace.axd.
After the trace limit, it stops tracing.

Jeffrey Palermo

"Brett Robichaud" <br************@nospam.yahoo.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Performance on our site is definitely not the top concern, just the standard 'it should be reasonably fast'.

Thanks for the insight on your own performance testing.

I'm curious about your last comment. It was my understanding that the trace request threshold was a rolling FIFO cache. You state that after 250
requests (assuming I set the limit at 250) it would stop tracing. Is this
true? I assumed it would just throw the top requests off the cache and keep tracing. If what you're saying is true then the usefulness of it for me is significantly reduced.

-Brett-

"Jeffrey Palermo" <je************@yahoo.com> wrote in message
news:eb**************@TK2MSFTNGP10.phx.gbl...
The performance hit is considerable, but it won't render the app unusable.
In fact, if your server fully loaded, I doubt the users would even notice. I've done performance testing with and without tracing, and tracing cuts my
requests/sec in half, but my normal usage is way lower than my stress
testing usage, so I wouldn't worry. Because you are considering tracing

in
production, I'm assuming that this isn't a "if the site is slow, we lose

$5
billion" application. After your 250 request threshold is reached, the
performance will increase again because tracing will be turned off.

Jeffrey Palermo

"Brett Robichaud" <br************@nospam.yahoo.com> wrote in message
news:e2**************@TK2MSFTNGP11.phx.gbl...
Does anyone know what kind of overhead is caused by enabling tracing in an ASP.NET 1.1 app?

On my production servers I'd like to leave it enabled so I can view
trace.axd to get a feel for the activity and problems on my site, I'd

leave
pageOutput="false". But I'm wondering what kind of extra load my servers experience due to this. Any ideas?

I'm also curious how bumping up the requestLimit increases the
overhead? I'd like to use a value of 250 or more.

I haven't found any documentation on the overhead associated with

tracing.
-Brett-



Nov 18 '05 #4

P: n/a
Wow, that is hugely dissapointing. To me that severly limits the usefulness
of tracing.

I am surprised there isn't at least an option to enable it to act as a FIFO
cache.

-Brett-

"Jeffrey Palermo" <je************@yahoo.com> wrote in message
news:O9****************@TK2MSFTNGP11.phx.gbl...
Yes, your fears are true. Test it out for yourself. Set the trace limit to 2, then hit your app. Only the first 2 requests will show up on trace.axd. After the trace limit, it stops tracing.

Jeffrey Palermo

"Brett Robichaud" <br************@nospam.yahoo.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Performance on our site is definitely not the top concern, just the

standard
'it should be reasonably fast'.

Thanks for the insight on your own performance testing.

I'm curious about your last comment. It was my understanding that the

trace
request threshold was a rolling FIFO cache. You state that after 250
requests (assuming I set the limit at 250) it would stop tracing. Is this
true? I assumed it would just throw the top requests off the cache and

keep
tracing. If what you're saying is true then the usefulness of it for me

is
significantly reduced.

-Brett-

"Jeffrey Palermo" <je************@yahoo.com> wrote in message
news:eb**************@TK2MSFTNGP10.phx.gbl...
The performance hit is considerable, but it won't render the app unusable. In fact, if your server fully loaded, I doubt the users would even notice. I've done performance testing with and without tracing, and tracing cuts my
requests/sec in half, but my normal usage is way lower than my stress
testing usage, so I wouldn't worry. Because you are considering
tracing
in
production, I'm assuming that this isn't a "if the site is slow, we
lose $5
billion" application. After your 250 request threshold is reached,

the performance will increase again because tracing will be turned off.

Jeffrey Palermo

"Brett Robichaud" <br************@nospam.yahoo.com> wrote in message
news:e2**************@TK2MSFTNGP11.phx.gbl...
> Does anyone know what kind of overhead is caused by enabling tracing

in
an
> ASP.NET 1.1 app?
>
> On my production servers I'd like to leave it enabled so I can view
> trace.axd to get a feel for the activity and problems on my site, I'd leave
> pageOutput="false". But I'm wondering what kind of extra load my

servers
> experience due to this. Any ideas?
>
> I'm also curious how bumping up the requestLimit increases the

overhead? > I'd like to use a value of 250 or more.
>
> I haven't found any documentation on the overhead associated with

tracing.
>
> -Brett-
>
>



Nov 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.