使用WSE 3.0 MTOM服务避免GC颠簸

Question

由于历史原因，我有一些WSE 3.0 web服务，我还不能在服务器端升级到WCF (这样做也需要大量的工作)。

这些web服务使用MTOM编码将文件从客户端传输到服务器。出于兼容性的原因，这在短期内也不能改变。其次，它们同时被Java和.NET调用，因此需要跨平台，因此MTOM也是如此。

它的工作原理是“上传”WebMethod由客户端调用，一次发送一大块数据，因为正在传输的文件可能有千兆字节大小。

但是，由于在调用WebMethod之前无法控制堆栈的各个部分，因此我无法控制web服务的内存使用模式。

我遇到的问题是文件大小在50MB左右，由于GC，性能绝对会被扼杀，因为WSE3.0似乎在一个新的byte[]数组中缓冲从客户端收到的每个块，而当我们完成50MB的时候，我们花费了20-30%的时间进行GC。

我尝试过不同的块大小，从16k到2MB，结果没有太大差别。

较小的块会被往返所涉及的延迟杀死，而较大的块只是推迟减速，直到GC开始工作。

关于减少WSE产生的垃圾有什么好主意吗？我能不能以某种方式插入到管道中，随意操纵一些可以访问客户端请求流并将其流式传输到WebMethod的东西？

我知道可以使用WSE将响应“流式”发送到客户端(尽管非常丑陋)，但这个问题与客户端的请求有关。

Answer 1

你的任务完成了。千兆字节传输和WSE 3.0永远不能一起工作--你基本上需要在WCF中进行流式处理。

您可以尝试使用64位进程并加载大量内存，这样GC就不是问题了。升级到.NET 4.0 (大多数情况下应该是无痛的)并使用非阻塞GC。使用12-30 12内存的进程，你应该能活得更久一些。

在历史上，所有的ASP (.net)东西都是“批处理”的，首先收集所有数据，然后发送它。THis意味着大型项目不能很好地处理。

Answer 2

作为一种解决办法，经过一些测试，似乎可以在同一个web应用程序中同时使用WCF服务和旧式ASMX Web Service，两者都具有.asmx扩展名，这将允许我使用流实现WCF中的文件传输web服务，而保持其余服务不变，并保留人们用来连接的原始URI。

它需要一些真正的丑陋的 BuildProvider和IHttpHandler黑客，但它确实有效。

简写：

1. 您实现了一个代理生成提供程序，该提供程序检查.asmx文件以确定它是WebService声明还是ServiceHost声明。然后在实际的构建提供程序(System.ServiceModel.Activation.ServiceBuildProvider或System.Web.Compilation.WebServiceBuildProvider)上调用适当的方法。请注意，您必须使用反射实例化目标构建提供程序，因为它们是内部的。您还调用了一些内部BuildProvider方法来模拟BuildManager所做的事情。
2. 您实现了一个IHttpHandlerFactory，它使用反射创建System.ServiceModel.Activation.HttpHandler (因为它也是内部的)，或者使用方便的、已经公开的System.Web.Services.Protocols.WebServiceHandlerFactory来创建旧的ASMX ASMX a，如下所示配置它们(假设您在IIS7上使用非集成模式)：

​

<?xml version="1.0"?>
<system.web>
    <compilation debug="true">
      <buildProviders>
        <remove extension=".asmx" />
        <add extension=".asmx" type="TestService.AsmxWcfSwitchingBuildProvider, TestService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
      </buildProviders>
    </compilation>
    <httpHandlers>
      <remove verb="*" path="*.asmx"/>
      <add path="*.asmx" verb="*" type="TestService.AsmxWcfSwitchingHttpHandlerFactory, TestService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" validate="false"/>
    </httpHandlers>
  </system.web>





Navigate to a legacy ASMX page. Verify that you can see the default page and WSDL.
Navigate to a WCF ASMX page. Verify that you can see the default page and WSDL.


Making sure you have parity with the original WSDL, and making sure your SOAP actions are correct, etc, is left as an exercise for the reader :)