February 2005 - Posts

MaintainScrollPositionOnPostback Property - I love it.
Friday, February 25, 2005 3:51 PM

With all the new features in .Net V2, its easy to miss things. You get busy looking at some of the more 'meaty' aspects, that you miss the small things. I have been enjoying and playing with lots of new ASP.Net V2 features such as the security controls, web parts. client callbacks etc.. that I never took the time to appreciate the ease and simplicity of a property in the System.Web.UI.Page object called 'MaintainScrollPositionOnPostback'. Sure, there is probably many of you out there who have already enjoyed the ease and simplicity of this boolean property, but its things like this that I really enjoy seeing.

Simple, works great, saves you time, and just shows that the designers of V2 have really done some homework from an ease of use and common usage scenario perspective.

Basically, just set this proeperty to true (eg. Page.MaintainScrollPositionOnPostback = true;) and javascript will be inserted into your rendered page, that maintains the scroll position in the browser window for all postbacks. Those of us who have done this manually, know that its not rocket science to achieve, but its sooooo nice to be able to set a single page property to just 'make it happen'.

As a final nice touch, if it could be a property in designer view (or am I blind?), that would be great.

WSE2 and the weird "WSE453" Error
Tuesday, February 22, 2005 11:24 AM

In our current project, we use web services extensively, and have built up all our external web service system communication using WSE2 and WS-Policy. Recently, on one individuals machine, they experienced the following error:

WSE453: an error was encountered loading or parsing the policy document in the following file "........\policycache.config"

A stack trace of te exception revealed an inner exception that stated:

"An entry with the same key already exists".

I tried for some time to fix this issue, and the same policy file was being used on a number of other developers machines (including my own) without issue. I tried many things, from using a different user to log on, shutting down a whole bunch of services on the machine, recopying over the policycache.config file and a bunch of others....

We finally found a solution, although I must admit I am at a loss to fully explain it. For the solution, read on:

Like most laptops, you can configure the ethernet port to AutoDetect the port speed. This laptop had the AutoDetect feature enabled, and was detecting the port at 100Mbs. Everybody elses laptop had the port speed set to 10Mbs because of previous network issues (unrelated and was time ago before this project) on the corporate network. When we set the port speed of this developers ethernet port to an explicit 10Mbs/Full Duplex, it worked!

Not really sure why, but can only guess that the parsing of the policycache file causes some network activity (whether it be a simple local lookup) or prior to sending of the message causes some network activity on the local machine, and the 100Mbs autodetect speed was causing this to fail, generating this error message. I would be happy to hear anyone elses thoughts. Googling this error doesn't produce much at all.

Maybe if Christian Weyer ever happens to read my blog, he can help me out.... :)

ASP.NET Performance Part 2 - Some testing Strategy
Tuesday, February 15, 2005 11:01 PM

As you may be aware, I am very involved in performance testing as of late with an application me and my team have been working on for some time. In a previous post, I mentioned an isolated form of performance testing or profiling, using the freely available CLR Profiler.

Another part of my testing toolset is Microsoft Application Centre Test or ACT. It comes with Visual Studio.NET 2003 Enterprise edition and allows you to simulate a browser accessing your web application under various loads. It has its fair share of critics in that its not the most full featured performance testing tool around, particularly when compared to some of the commercial offerings, but it still can provide you with a good degree of load simulation and statistics for your web application.

I am not going to go into an explanation of a majority of the features, statistics and reports available in this post (thats reserved for perhaps my next post), I do want to mention an extremely valuable test strategy that has worked very well for me in this situation.

Our app communicates with approximately 6 other systems, mostly via web services. Obviously there is a degree of latency involved that would effect the overall throughout of the application. In order to determine whether just the application can handle specific loads, we built a series of configurable switches into the app early on in its development, that allows us the "stub" the various external system calls, with local response data. This means we can turn of all external system calls, run the application at high loads, and determine how much of our application can handle in an ideal situation. Then we can selectively, enable the external systems under various loads and examine the effect this has on the performance. From this we can deduce whether problems (in terms of performance) lie within our application, the external systems or our handling of the communication with those systems.

We have found this ability absolutely invaluable in proving our applications ability and allowing us to easily isolate problem areas at many different levels. When your web applications become a series of complex interactions between a variety of systems, these simple configuration switches have been well worth their implementation effort.

In my next posts, I will be dealing with client side statistics generated from Microsoft ACT, as well as server counters used for statistic gathering an analysis from Windows performance monitor.

ASP.NET Performance
Wednesday, February 9, 2005 8:59 PM

I have been absolutely swamped lately with work, and in particular determining and rectifying performance issues with a major ASP.NEt application we are developing. Measuring, tuning, rectifying and reporting are all part of my current tasks. We are using only out of the box tools to do so, in particular, the CLR Profiler for memory profiling and Microsofts Application Centre Test for generating load. During this task, I have learned a couple of things. What is one of the most useful features of the .Net framework, but also one potentially one of the most dangerous?

Well, my answer is the Garbage Collector, or GC as its tentatively known. Its a fantastic thing, in that resources and memory is cleaned up on your behalf in a very efficient manner, eliminating some of the requirements of the old C/C++ days of manually having to release everything. It can also be lull developers into a false sense of security, especially where memory usage and performance is concerned. During my profiling of certain elements of the application, it became apparent that objects were being created and used all over the place, with the assumption that the GC would collect them later. Well as you can imagine, this lead to inefficient performance and memory consumption in many areas.

The CLR Profiler has been an invaluable tool for aiding me in determining whats going on, and where in the various parts of the application, which itself is quite large and complex.

Take a look at the comparitive "Histogram by Age" charts below.

Here is a link to the before image, and here is the after image.

This was from an isolated part of the application but is indicative of one of the many improvements that have been made using this tool.

This will also be part of a presentation that I hope to be making at TechEd 2005 in Australia at the Gold Coast later this year. I certainly have not been confirmed in any way, but have voiced my wish to present this kind of material. Hopefully, I get a chance to do so. If you feel this would be valuable, or even if you think it wouldn't be, I'd love to hear your opinion.

 

More Posts

This Blog

Syndication