Anyone with even a basic understanding of the complexitites of performance diagnosis knows that performance problems come from many different factors. Highlighting one potential cause of performance problems without even mentioning others (particularly in an official communication like a KB article) doesn't seem overly wise to me, and I put in some correspondance through the MVP program internal newsgroups on
KB article 307340 - PRB: High CPU Utilization in Web Service or Web Form on these grounds.
What I said was:
KB article 307340 (PRB: High CPU Utilization in Web Service or Web Form
http://support.microsoft.com/default.aspx?scid=kb;en-us;307340&Product
=aspnet) isn't an overly helpful article. Suggesting that it is
reasonable to correlate high CPU utilization on a web server with string
concatenation in the absence of any other supporting information is totally
unreasonable, and very unhelpful to the IT administrators charged with
diagnosing and fixing a run-away CPU problem, and the developer whose code
is running on the box.
IMO, the article should be scrapped entirely, or at a minimum, expanded to
included:
* a very clear statement that there are many other problems that can cause
this problem totally unrelated to string concatenation.
* include the Perfmon counters that can be used to test whether the problem
is string concatenation related. Looking at the ratio of generation 0
collections to gen 1 and gen 2 (a ratio of around 1 to 10 should exist
between the each generation step, excessive gen 0 collections indicate the
creation and collection of an excessive number of short lived objects) and
the % time in GC counter, all of which are available on the .NET CLR Memory
performance object.
* a link to the CLR profiler on MSDN so that string concatenation hypothesis
can be conclusively proved if perfmon backs up the assertion.
The response I got was that the article was technically accurate and will not be changed. After going to the effort of providing a fair amount of further information that could have enhanced the article, I'm disappointed that they choose not to include it. I've personally come across two occasions where this article has caused people to fly off to a conclussion without even attempting a proper diagnosis, and given this is one of the few articles that the Knowledge Base published on .NET performance, I would have hoped it would be a lot better.
Well, at least you are warned now...
Posted
Oct 25 2004, 09:48 PM
by
nick