SignalR似乎放慢我的MVC的启动/ Azure应用程序 [英] SignalR seems to be slowing startup of my MVC / Azure application

问题描述

我有运行的MVC应用程序在.NET 4.5在Windows Azure上的一个WebRole，使用SignalR 1.0 -alpha2，并使用ServiceBus背板。在我App_Start文件夹中我有RegisterHubs.cs，具体如下：

I have an MVC application running under .NET 4.5 on a WebRole on Windows Azure, employing SignalR 1.0 -alpha2, and using the ServiceBus backplane. In my App_Start folder I have RegisterHubs.cs, as follows:

[assembly: PreApplicationStartMethod(typeof(pageengine.studio.RegisterHubs), "Start")]

namespace pageengine.studio
{
    public static class RegisterHubs
    {
        public static void Start()
        {
            // Register the default hubs route: ~/signalr/hubs
            RouteTable.Routes.MapHubs();
        }
    }
}

和在Global.asax中，我有以下几点：

And in Global.asax, I have the following:

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
    FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    String connectionString = "Endpoint=sb://MYNAMESPACE.servicebus.windows.net/;SharedSecretIssuer=MY_ISSUER;SharedSecretValue=MY_SECRET_VALUE";
    GlobalHost.DependencyResolver.UseWindowsAzureServiceBus(connectionString, 1);
}

我已经运行测试，上述（称之为MVC + SignalR + ServiceBus），并在Global.asax中 GlobalHost.DependencyResolver ... 行注释掉（MVC + SignalR），与两行 [汇编：preApplicationStartMethod ... 和 RouteTable.Routes.MapHubs（）; 也注释掉（MVC当家）。

I've run tests as above (call this MVC + SignalR + ServiceBus), with the GlobalHost.DependencyResolver ... line in Global.asax commented out (MVC + SignalR), and with both lines [assembly: PreApplicationStartMethod ... and RouteTable.Routes.MapHubs(); also commented out (MVC Alone).

开始之前，我火了使用不开始调试（和部署到IIS防爆preSS）在Azure仿真器，并且每个注释/取消注释后，我重新构建应用程序，然后做谷歌浏览器的硬重装。有超过十次试验我的平均加载时间如下：

Before beginning, I fire up the Azure emulator using Start Without Debugging (and deploying to IIS Express), and after each commenting / uncommenting, I rebuild the application, then do a hard reload in Google Chrome. My average load times over ten tests are as follows:

MVC当家：1.33秒。

MVC Alone: 1.33 seconds

MVC + SignalR：31.95秒

MVC + SignalR: 31.95 seconds

MVC + SignalR + ServiceBus：53.1秒

MVC + SignalR + ServiceBus: 53.1 seconds

我没有运行在我的活天青站点相同的比较，但对于运行这些测试的原因在于，实施SignalR后，它正在运行速度会明显降低。

I have not run the same comparison on my live Azure site, but the reason for running these tests is that after implementing SignalR, it is running noticeably slower.

我曾以为这只是由于SignalR在阿尔法之中，但在其他地方讨论（<一个href=\"http://stackoverflow.com/questions/13579598/signalr-mvc-site-loads-indefinitely-after-signalr-install\">signalR MVC网站加载后signalR安装无限期）认为这不应该是这样的。我不知道，如果有什么问题我上面执行，或者如果这是一个Azure的具体问题，或别的东西。

I had assumed this was just due to SignalR being in alpha, but discussion elsewhere (signalR MVC site loads indefinitely after signalR install) suggests this shouldn't be so. I'm not sure if there is something wrong with my implementation above, or if this is an Azure-specific issue, or something else.

时其他人遇到类似的性能问题？有什么毛病我code以上？没有人有任何潜在的补救措施？

Is anybody else experiencing similar performance issues? Is there anything wrong with my code above? Does anyone have any potential remedies?

更新

我添加了一丝语句来WebRole启动和运行方式，以年初和 RegisterHubs 方法的结束，并开始和结束的的Application_Start 方法，并且注释掉ServiceBus code，所以我只是测试MVC + SignalR。

I've added a trace statement to the WebRole Start and Run methods, to the beginning and end of the RegisterHubs method, and to the beginning and end of the Application_Start method, and commented out the ServiceBus code so I'm just testing MVC + SignalR.

再次在若干测试，其结果是一致的：

Again, over a number of tests, the results are consistent:

Web角色的OnStart：20点55分17秒。

Web Role OnStart: 20:55:17

Web角色运行：20点55分17秒。

Web Role Run: 20:55:17

RegisterHubs开始：20点55分28秒。

RegisterHubs Start In: 20:55:28

RegisterHubs开出：20时56分10秒//42秒。平均较近45。

RegisterHubs Start Out: 20:56:10 // 42 seconds. Average was nearer 45.

在的Application_Start：20点56分14秒。

Application_Start In: 20:56:14

的Application_Start日期：20点56分21秒。

Application_Start Out: 20:56:21

有关参考，我RegisterHubs方法现在看起来是这样的：

For reference, my RegisterHubs method now looks like this:

public static void Start()
{
    System.Diagnostics.Debug.WriteLine("RegisterHubs Start In: " + DateTime.Now.ToLongTimeString());
    // Register the default hubs route: ~/signalr/hubs
    RouteTable.Routes.MapHubs();
    System.Diagnostics.Debug.WriteLine("RegisterHubs Start Out: " + DateTime.Now.ToLongTimeString());
}

进一步更新

问题是（讽刺的是）在 PerformaceCounterManager 类，在 Microsoft.AspNet.SignalR.Core 部件。

The issue is (ironically enough) in the PerformaceCounterManager class, in the Microsoft.AspNet.SignalR.Core assembly.

功能 SetCounterProperties（）超过23种不同的循环调用 LoadCounter _counterProperties 。每个电话出现故障和异常处理，导致 _noOpCounter 一回，但失败正在发生一至两秒，这个累积到四十第二滞后（所有这些计时与调试器 - 这是没有更快，当然，但还是事倍功半laggy）。

The function SetCounterProperties() calls LoadCounter over a loop of 23 different _counterProperties. Each of these calls fails and the exception is handled, resulting in a return of _noOpCounter, but the fail is taking between one and two seconds to occur, and this accumulates to a forty second lag (all these timings with the debugger on - it's quicker without, of course, but still perceptibly laggy).

下面是被处理的例外的痕迹，如果这是有用的：

Here's a trace of the handled exception, in case that's useful:

'System.InvalidOperationException'类型的第一次机会异常出现在System.dll中
InvalidOperation：SignalR - 错误：枢纽总调用 - deployment18（966）.Azure.Studio_IN_0_Web - System.InvalidOperationException：不能因为一个无效的索引''是从注册表中读取加载计数器名称的数据。
   在System.Diagnostics.PerformanceCounterLib.GetStringTable（布尔isHelp）
   在System.Diagnostics.PerformanceCounterLib.get_NameTable（）
   在System.Diagnostics.PerformanceCounterLib.get_CategoryTable（）
   在System.Diagnostics.PerformanceCounterLib.CategoryExists（字符串类）
   在System.Diagnostics.PerformanceCounterLib.CategoryExists（弦机，串类）
   在System.Diagnostics.PerformanceCounterCategory.Exists（字符串categoryName，字符串机器名）
   在System.Diagnostics.PerformanceCounterCategory.Exists（字符串categoryName）
   在Microsoft.AspNet.SignalR.Infrastructure.PerformanceCounterManager.LoadCounter（字符串categoryName，字符串counterName，字符串实例名）的d:\\Work\\CLIENTS\\PageEngine\\Resources\\SignalR-master\\src\\Microsoft.AspNet.SignalR.Core\\Infrastructure\\PerformanceCounterManager.cs:line 275

最简单的解决方法是没有PerformanceCounters。 <击>暂且我修改为getPropertyInfo（）来简单地返回新的PropertyInfo [0] 。< /罢>我修改 LoadCounter 总是返回 _noOpCounter 。现在的启动时间约5秒，或10的服务总线。

Easiest workaround I could find was to have no PerformanceCounters. For the time being I've modified GetPropertyInfo() to return simply new PropertyInfo[0]. I've modified LoadCounter to always return _noOpCounter. Startup time is now about 5 seconds, or 10 with the Service Bus.

推荐答案

这是SignalR 1-α2，一个bug，现在在GitHub上报道：的 https://github.com/SignalR/SignalR/issues/1063

This is a bug in SignalR 1-alpha2, now reported on github: https://github.com/SignalR/SignalR/issues/1063

更新

...现在固定：的https://github.com/SignalR/SignalR/commit/fda3aa41a9250a072e8487882ae806ffe547f2bb

这篇关于SignalR似乎放慢我的MVC的启动/ Azure应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！