Saturday, January 10, 2004 2:55 PM
In recent times I have been seeing a lot of enthusiasm and awareness going on about performance. for instance Cowell Shah has an interesting article comparing performance between 9 different languages it makes an interesting read about how languages supported by .net perform comparing to each other.
http compression topics are being most talked about especially after this post by scott and now GWB started giving out RSS feeds with compression on :).
Sudhakar has a write up about HttpCompression on his blog too.
Ofcourse it was nice to see people writing about Asp.Net perf testing & monitoring. For example Darell Norton writes in his post regarding tools which can be used to stress a web application. I happened to participate in the stress testing & in finding out facts & figures for the application which we developed and I happen to become after that a perf freak. I spend quite a bit of time thinking about the way I write every single method given the circumstances how the method would be invoked & how the result would be rendered back to the browser.
IMHO I strongly believe that performance should be a key element during code reviews and developers should be educated to inhibit themselves from writing code which simply compiles to the functional requirements. I believe verifying functionality & other code defects in code does not make up code review; What really a reviewer should do is to give value additions to the reviewing process with the amount of experience he / she has in the relevant area of expertise say for instance with the lessons I have learnt the hard way when I do reviews I also see in case if some code could be better written to perfor better I sure comment it in the dev bug database.
A Developer should see that code which might be the smartest way to add 2 numbers but performance wise could suck should NOT be written in the first place itself.
I get a lot disappointed to know when people think that stress testing a web application is limited to using ACT or WAST a.k.a Homer. For them I would like to reiterate that this way you are baselining the figures for the server & the app that given a specific set of base parameters like hardware & other params the app is able to handle n amount of concurrent connections.
The fact lies that individual pages in the app should be stress tested using performance counters & tracing (this is one hell of a feature in asp.net applications which can really make the difference in evaluation preformance of your asp.net app) on the web server to achieve a desired amount of concurrency and lead to tuning the code / application and removing pain points in a web application.
I remember days when I used to browse the internet over a 28.8kbps dial up connection and disabled images etc.. to be rendered on the browser cos I could not afford waiting for the entire page to load. I want to strieve the fact that every method processed or used to render output (the time it takes), every DB call done, every byte sent out from the server to the browser, amount of time it takes for the browser to actually render the page on the client browser (esp depending on his internet connectivity options && browser engine in certain cases) really make a difference to people who end up using application which we developers write !!