c# - 在新 AppDomain 中建立的第一个 WCF 连接非常慢

Question

我有一个我使用的库，它使用 WCF 调用 http 服务来获取设置。通常第一次调用需要大约 100 毫秒，后续调用只需要几毫秒。但我发现，当我创建一个新的 AppDomain 时，来自该 AppDomain 的第一个 WCF 调用需要超过 2.5 秒。

对于为什么在新的 AppDomain 中第一次创建 WCF channel 会花费这么长时间，有没有人有解释或修复？

这些是基准测试结果(在 64 位版本中没有附加调试器的情况下运行时)，请注意在第二组数字中，第一个连接如何花费超过 25 倍的时间

Running in initial AppDomain
First Connection: 92.5018 ms
Second Connection: 2.6393 ms

Running in new AppDomain
First Connection: 2457.8653 ms
Second Connection: 4.2627 ms

这不是一个完整的示例，但展示了我如何生成这些数字的大部分内容:

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Running in initial AppDomain");
        new DomainRunner().Run();

        Console.WriteLine();
        Console.WriteLine("Running in new thread and AppDomain");
        DomainRunner.RunInNewAppDomain("test");

        Console.ReadLine();
    }
}

class DomainRunner : MarshalByRefObject
{
    public static void RunInNewAppDomain(string runnerName)
    {
        var newAppDomain = AppDomain.CreateDomain(runnerName);
        var runnerProxy = (DomainRunner)newAppDomain.CreateInstanceAndUnwrap(typeof(DomainRunner).Assembly.FullName, typeof(DomainRunner).FullName);

        runnerProxy.Run();
    }

    public void Run()
    {
        AppServSettings.InitSettingLevel(SettingLevel.Production);
        var test = string.Empty;

        var sw = Stopwatch.StartNew();
        test += AppServSettings.ServiceBaseUrlBatch;
        Console.WriteLine("First Connection: {0}", sw.Elapsed.TotalMilliseconds);

        sw = Stopwatch.StartNew();
        test += AppServSettings.ServiceBaseUrlBatch;
        Console.WriteLine("Second Connection: {0}", sw.Elapsed.TotalMilliseconds);
    }
}

对 AppServSettings.ServiceBaseUrlBatch 的调用正在创建服务 channel 并调用单个方法。我已经使用 wireshark 来观看通话，只需要几毫秒就可以从服务中获得响应。它使用以下代码创建 channel :

public static ISettingsChannel GetClient()
{
    EndpointAddress address = new EndpointAddress(SETTINGS_SERVICE_URL);

    BasicHttpBinding binding = new BasicHttpBinding
    {
        MaxReceivedMessageSize = 1024,
        OpenTimeout = TimeSpan.FromSeconds(2),
        SendTimeout = TimeSpan.FromSeconds(5),
        ReceiveTimeout = TimeSpan.FromSeconds(5),
        ReaderQuotas = { MaxStringContentLength = 1024},
        UseDefaultWebProxy = false,
    };

    cf = new ChannelFactory<ISettingsChannel>(binding, address);

    return cf.CreateChannel();
}

从分析应用程序可以看出，在第一种情况下，构建 channel 工厂、创建 channel 和调用方法所需的时间不到 100 毫秒

在新的 AppDomain 中构建 channel 工厂耗时 763 毫秒，创建 channel 耗时 521 毫秒，调用接口(interface)方法耗时 1,098 毫秒。

TestSettingsRepoInAppDomain.DomainRunner.Run() 2,660.00TestSettingsRepoInAppDomain.AppServSettings.get_ServiceBaseUrlBatch() 2,543.47Tps.Core.Settings.Retriever.GetSetting(字符串,!!0,!!0,!!0) 2,542.66Tps.Core.Settings.Retriever.TryGetSetting(字符串,!!0&) 2,522.03Tps.Core.Settings.ServiceModel.WcfHelper.GetClient() 1,371.21Tps.Core.Settings.ServiceModel.IClientChannelExtensions.CallWithRetry(类 System.ServiceModel.IClientChannel)1,098.83

编辑

在将 perfmon 与 .NET CLR 加载对象一起使用后，我可以看到，当它加载第二个 AppDomain 时，它正在将比最初更多的类加载到内存中。第一条平线是我在第一个 appdomain 之后放置的暂停，它加载了 218 个类。第二个 AppDomain 导致总共加载 1,944 个类。

我假设它一直在加载所有这些类，所以现在的问题是，它正在加载哪些类，为什么？

更新

答案原来是因为只有一个 AppDomain 能够利用 native 图像系统 dll。因此，第二个应用程序域的缓慢之处在于它必须重新编译 wcf 使用的所有 System.* dll。第一个 appdomain 可以使用这些 dll 的预生成 native 版本，因此它没有相同的启动成本。

在调查了LoaderOptimizationAttribute之后Petar 建议，这确实似乎解决了这个问题，使用 MultiDomain or MultiDomainHost导致第二个 AppDomain 花费与第一次通过 wcf 访问内容相同的时间

在这里您可以看到默认选项，请注意在第二个 AppDomain 中没有一个程序集说 Native，这意味着它们都必须重新编译，这就是一直花费的时间

这是在将 LoaderOptimization(LoaderOptimization.MultiDomain) 添加到 Main 之后。可以看到所有东西都加载到了共享的AppDomain

这是在用户 LoaderOptimization(LoaderOptimization.MultiDomainHost) 到 main 之后。您可以看到所有系统 dll 都是共享的，但是我自己的 dll 和任何不在 GAC 中的 dll 都分别加载到每个 AppDomain 中

所以对于提示这个问题的服务，使用 MultiDomainHost 就是答案，因为它具有快速启动时间，我可以卸载 AppDomains 以删除服务使用的动态构建的程序集

Answer 1

您可以用 LoaderOptimization 装饰 Main属性告诉 CLR 加载器如何加载类。

[LoaderOptimization(LoaderOptimization.MultiDomain)]
MultiDomain - Indicates that the application will probably have many domains that use the same code, and the loader must share maximal internal resources across application domains.