c# - 将HTTPS用于Web服务或Web请求时的内存使用问题

Question

编辑：在评论中进行了长时间讨论之后，似乎我的原始问题并未真正反映出正在发生的事情。这是我现在所在位置的摘要：


当使用HTTPS时，在我提出第一个HTTPS请求（Web服务调用，WebClient.DownloadFile（）等）时，我会认为应用程序的虚拟内存空间发生了急剧的跃升（通常从50mb以下跃升到200mb以上）。
同时，CPU内核的使用率也接近100％。这通常只持续几秒钟，但我看到它的持续时间更长
很有可能这只是使用HTTPS的代价，但我对此感到惊讶，因为我之前从未在其他应用程序中注意到它（而我团队中的其他开发人员也从未在此应用程序中注意到它，早在我上任之前就使用HTTPS）。
更重要的是：这似乎并非在所有机器上都发生，但在大多数机器上都会发生。如果它在每台机器上都持续发生，我将更愿意将其视为“业务成本”。但是由于某些运行相同代码的计算机和操作系统之间似乎确实存在差异，所以我想理解为什么会这样，因为它要么a）允许我们减轻这种行为，要么b）以一种令人满意的方式对其进行解释非技术性的高手，这实际上不是一个“问题”，因为到目前为止，Windows Task Manager可以显示虚拟内存，而不一定主动使用的物理内存并不能令人满意：/


如果有人有兴趣，我将原始帖子保留在下面，但它更多地关注Web服务，而这并不是问题的根源。

预先感谢您提供任何进一步的见解！



每当我们的应用程序首次使用https调用我们的Web服务时，我们就会看到内存使用量急剧增加。具体情况因机器而异，但例如，当进行第一个Web服务调用时，我们可能会看到我们的应用程序从〜50mb跃升到250mb以上，并且使用率从未下降。后续调用不会导致另一个此类跳转。我可以使用下面的代码（不是特定于我们的应用程序）和我们不拥有的公共Web服务来重现该行为，因此它似乎独立于我们的客户端和服务器端代码。

有趣的是，在我的测试应用程序中，我没有在Windows XP上看到这种跳跃（我们的应用程序当前仅部署在Windows 7上）。我们也没有在办公室的每台开发/测试机器上看到它（但是我们在大多数机器上都看到了），并且我们目前还没有办法从“真实世界”中的机器上检索此信息。

我无法确定正在分配的内容，但一些分析器已经清楚地表明它驻留在本机（非托管）内存中。使用DebugDiag对某些WinDbg转储进行的分析使我相信，在crypt32.dll中分配了很多未释放的内存。这在某种程度上是有意义的（https表示证书，安全性等，并且可能正在缓存正在加载的内容，因此为什么后续调用不会导致额外的跳转），但是我很难相信这是实际上只是将https用于Web服务的成本。

我知道“如果更高的内存使用率不会引起问题，为什么会担心？”将会有一些回应。营。总的来说，我同意-任务管理器中的内存使用率数字通常并不表示该应用程序是否按预期工作。如果该应用程序严格在内部使用，则只要它不是其他问题的征兆，我就可以接受。但是我们的应用程序已部署在消费类计算机上，因此我们必须像实际问题一样担心问题的感知。因此，如果有解决此问题的方法，我将不胜感激！

最后，在下面的测试代码中使用的Web服务在这里可用：http://ws.cdyne.com/emailverify/Emailvernotestemail.asmx?wsdl。 EmailVerNoTestEmail的代码是使用wsdl.exe工具生成的，并稍作修改，即将URL作为参数传递给构造函数，而不是对其进行硬编码（以便可以即时指定http / https）。

public static void Main(string[] args)
{
    const string urlSuffix = "://ws.cdyne.com/emailverify/Emailvernotestemail.asmx";
    string protocol = null;
    while(protocol == null)
    {
        Console.Write("Enter protocol (http, https): ");
        var line = Console.ReadLine();
        if (line != null) line = line.ToLower();
        if (line == "http" || line == "https")
            protocol = line.Trim();
    }
    var url = protocol + urlSuffix;
    Console.WriteLine("Using URL: " + url);
    Console.Out.Flush();

    var service = new EmailVerNoTestEmail(url);

    Console.WriteLine("Press any key to make the web service call...");
    Console.ReadKey(true);

    Console.WriteLine("Calling web service...");
    var resp = service.VerifyEmail("test@gmail.com", "test");
    Console.WriteLine("Response: " + resp);

    Console.WriteLine("Press any key to exit.");
    Console.ReadKey(true);
}

Answer 1

除非对系统施加压力，否则将其保持在一定的内存级别是很自然的。操作系统具有试探法，该试探法确定需要多少内存，并分配给大于所需内存的最高点。为什么？分配和释放内存的成本很高，并且如果程序可以在给定的自己的沙箱中运行，那么如果不对系统施加压力，为什么要减少它。

正如您所提到的，关注的不是分配的内存量，而是内存的泄漏。我建议您运行perfmon并监视泄漏；阅读此MSDN CLR文章Investigating Memory Issues中需要注意的内容。

编辑：（这是我之前给出的建议，但可能与主题重复有关/很抱歉）

要查看内存泄漏的明显迹象，可以启动性能监视器，并在性能监视器中查看这些字节的专用字节。请参阅Identify And Prevent Memory Leaks In Managed Code开始该过程。

Windows任务管理器的“进程”选项卡上还有一个要使用的进程。 （查看+选择列），检查句柄，GDI对象和USER对象。观察程序的这些值。如果没有手柄泄漏，您将看到其中之一稳步攀升。在这些情况下，GDI很有可能发生。通常，当OS运行应用程序时，它将尝试确定正在使用多少内存。它将为应用程序分配应用程序当前需要的更多内存。这样做的原因是分配/取消分配内存是CPU密集型操作。当应用程序可以驻留在内存池中时，为什么要并行处理该应用程序需要什么，这将允许该应用程序在不受操作系统干扰的情况下扩展和收缩。节省周期。开发人员看到的是存储器的高水位标记。如果没有给系统施加压力，则系统将不会回收任何内存并保持高水位标记。这个论坛上有很多帖子，用户说处理完毕，内存被清理了，但是操作系统仍然在内存点X（应该是内存点M（下））上显示我的应用程序。 Winform用户报告相同，但如果将应用程序最小化，则报告的内存使用率突然下降到该M级别。这是设计使然。最小化表明应用程序不需要内存，因为它不会与用户交互，并且操作系统将收回这一点。如果它不是Winform，并且没有对操作系统施加压力，则该应用程序将停留在X的高位。