7

I believe that the mvc mini profiler is a bit of a 'God-send'

I have incorporated it in a new MVC project which is targeting the Azure platform. My question is - how to handle profiling across server (role instance) barriers?

Is this is even possible?

Andrew Harry
  • 13,773
  • 18
  • 67
  • 102

2 Answers2

2

I don't understand why you would need to profile these apps any differently. You want to profile how your app behaves on the production server - go ahead and do it.

A single request will still be executed on a single instance, and you'll get the data from that same instance. If you want to profile services located on a different physical tier as well, that would require different approaches; involving communication through internal endpoints which I'm sure the mini profiler doesn't support out of the box. However, the modification shouldn't be that complicated.

However, would you want to profile physically separated tiers, I would go about it in a different way. Specifically, profile each tier independantly. Because that's how I would go about optimizing it. If you wrap the call to your other tier in a profiler statement, you can see where the problem lies and still be able to solve it.

Anže Vodovnik
  • 2,325
  • 16
  • 25
  • 2
    while the request is executed on a single instance, the default implementation of the profiler is such that the result is stored in the current ASP.Net Cache and is then supplied to the client using an ajax call - and that ajax call isn't guaranteed to hit the same server. – Stuart Jul 27 '11 at 17:14
  • To be honest, for profiling sake, I'd profile directly on the remote instance and not even go through the load balancer. I want to eliminate external services when profiling not figuring out if they had anything to do with it. But Having said that, I also agreenwith your answer on how you could make it work regardless. But, again, I would profile using RDP directly on an instance. – Anže Vodovnik Jul 28 '11 at 06:52
  • I agree with you in part... However, sometimes you want to investigate problems that occur in production - i.e. under normal operating load - and you can't really do this if you use RDP as this takes the web server out of the load balancer list. This is only one situation, though, and I accept that there are many other situations where you can use the RDP solution. – Stuart Jul 29 '11 at 09:39
  • Stuart, where did you see it is taken out of the Load Balancer list? Since I didn't believe you, I went ahead and did a test - and the load balancer routed requests to **both** of my instances (succesfully) while I RDPed to instance 0. – Anže Vodovnik Jul 29 '11 at 12:15
  • I don't know where I heard this - I'd guess either from the pdc2010 live streaming or in a followup uk tech event - but I am definite I was told this. I've just looked at http://msdn.microsoft.com/en-us/gg502181 and you look correct - so apologies (and thanks!). – Stuart Jul 29 '11 at 12:36
  • 1
    Last time I checked, this site is meant for knowledge exchange, so you're welcome :o) Just btw, in case it were true, you are right, it would render the profiler useless for this (quite real) scenario. – Anže Vodovnik Jul 29 '11 at 12:52
2

By default the mvc-mini-profiler stores and delivers its results using HttpRuntime.Cache. This is going to cause some problems in a multi-instance environment.

If you are using multiple instances, then some ways you might be able to make this work are:

  • to change the Http Cache to an AppFabric Cache implementation (or some MemCached implementation)
  • to use an alternative Storage strategy for your profile results (the code includes SqlServerStorage as an example?)

Obviously, whichever strategy you choose will require more time/resources than just the single instance implementation.

Stuart
  • 66,722
  • 7
  • 114
  • 165