profiler

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?

---

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.

---

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.

链接地址: http://www.djcxy.com/p/53918.html

上一篇: 在课堂上收集

下一篇: 探查