Tuesday, 23 October 2012

Getting all profile happy with JustTrace

Recently I have been developing a fair size application and so far everything seemed to be "just working" fine. However during testing I noticed a few times the app seemed to stall up. This left me quite unhappy and I knew it was time to relook at some of my "decisions". Initial glances through the code didn't really highlight anything so I thought it about time to profile the application and see what it can find.

In the past I have used Redgate's Ants Profiler and an early version of Telerik's JustTrace. I decided to give Telerik's JustTrace a go again as I have heard alot about it and wanted to see how it's changed / grown.

Alas, my initial attempt to use JustTrace ended quite abruptly, I've been developing on Windows 8 and VS2012 exclusively for about 5 months now and sadly JustTrace didn't support IIS8 or IIS Express 8. I was gutted to find this out but a quick chat to the Telerik Dev Team and Chris Eargle gave me hope as they advised me the Q3 update was right around the corner, 1 week to be exact, and it brought all the new toys into the game,

HURRAH!

So tonight I got it all updated and fired up, and started profiling my app. Profiling is immensely easy to perform, simply enable justtrace in the Telerik menu and hit F5 :) You are asked how you want to profile, i chose to simply [].

You then simply start using your application like normal and JustTrace sits there observing and recording what it is up too. Once you have spent some testing you can really start digging around. The first thing to notice is the Timeline view, this is showing all the CPU activity whilst running through the application. You want to start looking at where you have some peaks, and in particular extended CPU activity.
Timeline View
By clicking on an area of the timeline you get a larger view where you can highlight a time snapshot to view.
Show Snapshot

You can then look at a ton of options to find your issue, by looking at the call trees across all threads, all methods and even look straight into "hot spots". Hot spots are each threads expensive method in terms of time. In my current snapshot Assembly.Load was very expensive, but this was app startup, not what I was noticing.

Hot Spot View


By looking at the other peaks I did find where 3 seconds was going, executing queries against the database. Now this could be down to bad queries, but its more likely to be a bad use of Linq with Entity Framework, and not compiling queries etc. However now I know where to look and it only took me 5 - 10 minutes of profiling to find out. Fantastic, stuff and I've not even touched memory profiling !

My Hot Spot
Hopefully I can do before my trial runs out, but so far it looks worthwhile investing in, here's hoping I can get some BizSpark discount ;)

Wednesday, 10 October 2012

Deploying Non Project Files with Web Deploy

Deploying Websites and Web Applications has changed massively over the years, I have seen the likes of FTP, Copy & Paste over RDP (why!!) etc but there has always been a degree of, did I copy the correct files, did I miss any, did I upload the correct client config etc.

Since VS2010 I have been a big fan of always publishing my applications to either a local folder and then upload or directly to the server, depending on the setup.

One thing I have always struggled with is publishing files that aren't part of my project, and ensuring the correct client config settings are uploaded. Now I'm running VS2012 full time I decided it was time to put to bed these issues and ensure I could use one click, or as near to one as possible, to deploy stage configurations of my applications as well as live.

VS2012 has tweaked publishing again, it now includes a much fuller publish model, with WebDeploy amongst the usual FTP, FileSystem etc. The Package / Publish process is just an extension of MSBuild, which means you can perform any process / action that you would normally do with MSBuild, this could mean perform minimization / compression of css / js etc. Other people have written about this, http://sedodream.com/2011/02/25/HowToCompressCSSJavaScriptBeforePublishpackage.aspx

When you deploy MSBuild performs two steps, first of all it bundles all your content into a temporary location and then copies it all to the final location, or compiles a package if that's what you have configured

What I needed to do was alter the process to pull in some additional files into the temporary location so that they then get published to the final place.

This is possible by extending the PipelineCollectFilesPhaseDependsOn phase. We can simply add a build target to our file and then run this in the PipelineCollectFilesPhaseDependsOn phase.

Our Target:


<Target Name="CopyIOCFiles">
    <Message Text="Copy IOC Files" Importance="high"/>
    <ItemGroup>
      <_CustomFiles Include="$(ProjectDir)\IOC\**\*" />
      <FilesForPackagingFromProject  Include="%(_CustomFiles.Identity)">
        <DestinationRelativePath>bin\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
      </FilesForPackagingFromProject>
    </ItemGroup>
  </Target>

It's worth noting here that my target could just contain the ItemGroup element however I like to know the target has run so by sticking in a message element we know it's ran by looking at our build output,

This target is then run in the correct phase via the following:


 <PropertyGroup>
    <PipelineCollectFilesPhaseDependsOn>
      CopyIOCFiles;
      $(PipelineCollectFilesPhaseDependsOn);
    </PipelineCollectFilesPhaseDependsOn>
  </PropertyGroup>

Hurrah! That's it, actually a lot easier than I thought, when you combine this with web.config transformations on a per configuration basis you really can deploy one application in several configurations in one click.