Colin Beales - Blog

I was discussing with a customer the other day around the posibility of hitting the maximum path limit in TFS.

Great to see just days after the conversation a sample from James Pickell showing a Check-In policy to avoid this.

Sean Lumley has written an excellent blog article detailing how to debug pages that fail under load: http://blogs.msdn.com/slumley/pages/debugging-errors-in-load-test.aspx 

We have this requirement quite a bit in our performance and scale lab sessions when apps start to be put under stress that force different (and mostly unexpected) results from the time when they were recorded. This will be a great set of steps to help find the root cause.

I'm always forgetting this one and people often ask me for it so I'm popping up here in the hope I'll find it easier next time.

It's an old problem where Visual Studio 2005 goes looking to connect automatically to TFS when you change between TFS servers or work disconnected for a while.

Simply add a registry key "AutoLoadServer" (type DWORD) to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation, setting the value to be 0 (Do not connect automatically).

I had a colleagues customer ask today if it were possible to change the distribution for think time in load tests.

It turns out it is, but unfortunatly not through the UI. The .loadtest generated by the UI is simply XML and each scenario you have within would have an entry like this:

<Scenario Name="Scenario1" DelayBetweenIterations="2" PercentNewUsers="0" IPSwitching="true" TestMixType="PercentageOfTestsStarted">

      <ThinkProfile Value="0.2" Pattern="NormalDistribution" />

 Simply edit the ThinkProfile Value from 0.2 for the value you require. 

I was asked by a colleague today how to perform string concatenation in a web test for a query string they were wanting to be built up of some content from the data context and a hardcoded value. They wanted to do this without resorting to code in a plugin.

In order to support this the web test can simply have the hardcoded value next to the datacontextvalue i.e. "MyHardcodedString{{MyDataContextValue}}"

The web test will parse out and replace the data context value for you and do the concatenation. In this case they put this in their query string, but the same principle could be used in other places such as form posts also. Often this principle is used when replacing values from web service calls as the {{MyDataContextValue}} value can be pulled out and replaced with a data context bound value such as something from a datasource. See the docs on MSDN for more information on the seb service databinding: http://msdn2.microsoft.com/en-us/library/ms182546(VS.80).aspx

Just came across this on Neno Loje's Blog which is sooooooo cool. How cool is it to have access to the web access stuff direct from notification emails...Awesome!!

http://msmvps.com/blogs/vstsblog/archive/2007/08/31/changing-tfs-email-notifications-to-link-to-team-system-web-access.aspx

Just a quick note as I couldn't find it anywhere during a quick search during my lab. I wanted to see if the Load Test results recorded from the 2005 edition of Visual Studio Team System would be viewable in Orcas.

Thankfully I happy to say as of Beta2 this works just fine. In fact you can make the most out of some of the great new features in the post test run ui which will make analysis an even better experience. See Sean Lumley's blog for for further info on the new Orcas UI for post test run analysis: http://blogs.msdn.com/slumley/pages/load-test-execution-post-run-ui-enhancements.aspx.

One of the activities I get involved in with customers as an ADC is to work with customers in our performance and scalability labs at our UK headquarters in Reading. These labs involve a customer bringing their solution to our facility and building up load on this so that we can analyze, and tune out bottlenecks from the solution. Its a great activity to run with customers and each lab week is unique and fun to work on.

Obviously in such a lab we often are testing web based applications and as such need a tool to generate, co-ordinate and measure load across the whole test environment. In such a scenario this places VSTS Load Testing as the obvious tool for the job.

VSTS Load Testing is a great product and has some fantastic features within it and during the lab weeks it proves time after time to be an essential tool to a successful lab.

One area however the current version of the tool falls short on for our customers is around the portability of their test results which they understandably want to take back to their offices after the hard work during the lab.

The test results in VSTS Load Testing can potentially be quite large and as such unlike WebTest or UnitTest runs the results are not stored in the .trx files generated at the time of the test run. Instead in load testing the results are sent to a database (SQL or SQL Express) configured on the load testing controller machine in Visual Studio (Test Menu->Administer Test Controller) and this database itself is referred to by the .trx file as a encrypted connection string.

Here's where the problem lies obviously with labs like these the chances are that you generate quite a few different sets of test run results and when you come to move these test results from the test rig (in our case in our Microsoft offices) to another database (in our case our customer offices) the connection string is no longer valid.

Thankfully I found an article from a great VSTS blog here: Archi - http://barmagy.com/blogs/archi/archive/2006/12/28/20.aspx that discusses how we can manually edit each of our test run .trx files to change the m_resultsRepositoryConnectString to one for the new database. Essentially this requires you to restore your database and setup VSTS Load Testing (Test Menu->Administer Test Controller) to point to the new restored database. From this point we can get hold of the connection string in the valid encrypted state that connects this load test controller to the database (you can get this if you run a new load test on this machine and find the m_resultsRepositoryConnectString in the .trx file for this new run, or just grab it out the registry at HKCU\Software\Microsoft\VisualStudio\8.0\EnterpriseTools\QualityTools\Controller\LoadTestResultsConnectString)

This is a great solution but as I mentioned in my case my customers often have many test runs from the lab session and so I decided to knock up a small sample to go through a directory (and if required it's subdirectories) to change make this change to all the .trx files. If you want the code you can find it posted here.

Simply run the app after you've restored the database and configured the controller to point at this restored database instance. Select your target directory(s) and let it take the manual steps out the process.

Thankfully this problem will be fixed in the Orcas release of the load testing tools. You can see some further details at Sean Lumleys blog: http://blogs.msdn.com/slumley/pages/managing-load-test-results.aspx

For sometime now I have been threatening to start writing a blog, finally it would seem if this makes it online then I've done it. The truth is that I'm really not sure whether I'm going to get blog fever or if this will become one of those never to be updated weblogs. Time will tell.

In customary first blog entry here are a few notes about me, after that I guess I'll put up a bit of a bio page and if I get any hits on that I'll know my mum has been looking me up on Live Search!

I work in Microsoft Services in the UK in a team titled Application Development Consulting as an ADC (Application Development Consultant). My role as enables me to work with a host of great customers working with our development technologies.

As our team cover the entire Microsoft technology set we have the chance to specialize in areas of technology and at the moment my field is Team Foundation Server and the associated Visual Studio Team System client tools, I only mention this as it's likely that many of my posts may be around this area.

I've worked in my role for around 6 years now, prior to this I worked for 4 years in various roles in Microsoft working with customers in through our COM/COM+ and Visual C++ teams.

Right enough of the bio, on with the blog ....