mvc-mini-profiler - 使用负载平衡的 Web 角色（azure 等）
我相信 mvc mini profiler 有点像“天赐之物”，
我已将它合并到一个针对 Azure 平台的新 MVC 项目中。 我的问题是 - 如何处理跨服务器（角色实例）障碍的分析？
这可能吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（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.
默认情况下，mvc-mini-profiler 使用 HttpRuntime.Cache 存储并交付其结果。这会在多实例环境中导致一些问题。
如果您使用多个实例，那么您可能能够完成此工作的一些方法是：
显然，无论您选择哪种策略都将需要比单实例实现更多的时间/资源。
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:
Obviously, whichever strategy you choose will require more time/resources than just the single instance implementation.