You should check out the stitch tool from live labs.
Monthly Archive for June, 2009
Jun
09
2009
The Pier at David E Brink Park
Late night stroll at the David E. Brink Park
There was cool breeze unlike the bitter winds of December. The lake was alive with the winds and the sounds around. I love the fact that you can taste the water in the air and smell the fresh grass on the banks. Wished it was this nice all year around.
Here is a quick way to get an idea of how long your request/response takes and a ton of more data regarding your payload.
neXpert is an add-on to Fiddler Web Debugger which aids in performance testing web applications. neXpert was created to reduce the time it takes to look for performance issues with Fiddler and to create a deliverable that can be used to educate development teams.
Blog – http://blogs.msdn.com/nexpert/
Video- http://msdn.microsoft.com/en-us/dd573302.aspx – (4 minutes)
Introduction – http://blogs.msdn.com/nexpert/archive/2009/02/10/introducing-nexpert.aspx
Jun
04
2009
The Channel Pump
Deep dive – Nicholas Allen’s talk on WCF performance and Scale – PowerPoint Deck – Webcast
From the above talk you get an idea of the pull and the push model and a combination of these for certain channels. This defines how the message will be received on the transport and how they will be dispatched. Consider a pump as a loop doing some work. A pump works off a queue which it would push work on for the next layer or pulls work off when there is some work to be done.
Considering a very common scenario like basic http where a message would arrive on the transport. The flow would consist of 2 loops.
 |
Dispatcher/Message Pump1. Dispatcher gets a message. It has available resources and will dispatch the operation(Application) Channel Pump1. Pump registers that it can take pull a message. |
All channels affect how messages arrive and how they would be dispatched. We make a fundamental assumption in WCF that channels would always be fast. This is because of the fact that the channel is your infrastructure and it makes sense to put any heavy work to the application layer and not the channel layer.
So general rule of thumb – Do not do blocking or heavy work in your channels. Pass on the work to the upper application layer.
You should think of your channel as gate to your dispatcher and you don’t want to block the gate from letting the next person in. Hence bottom line is that a slow channel is a suboptimal channel.