设计高性能的WCF解决方案.ppt

设计高性能的WCF解决方案,Mauro Ottaviani 资深软件开发主管 微软公司,日程,回报 传输层，序列化器，及编码器 客户端的选项 服务端的选项 流传输 通常的建议,一些比较,与下列.NET技术具有可比性 .NET Remoting System.EnterpriseServices System.Messaging http:/msdn2.microsoft.com/en-us/library/bb310550.aspx 速度比以下网络服务更快 ASMX（ASP.NET网络服务） WSE 性能优于其它同类技术 http:/msdn2.microsoft.com/en-us/netframework/bb499684.aspx,.NET Remoting vs WCF,EnterpriseServices vs WCF,ASMX vs WCF,WSE vs WCF,日程,回报 传输层，序列化器，及编码器 客户端的选项 服务端的选项 流传输 通常的建议,传输层基础,WCF默认支持多种传输层 TCP, HTTP, MSMQ, NamedPipes 可以自定义其它传输层 每一种传输层各有不同的考虑因素 消息传输模式，可接受客户端的多寡，互操作性，开销,传输层的比较,序列化器基础,消息类型 = XML Infoset 序列化器是对象图与Infosets之间的桥梁 WCF自带了三种序列化器 DataContractSerializer (DCS) NetDataContractSerializer (NDCS) XmlSerializer 可应互操作性的要求使用相应的序列化器,编码器基础,编码器是Infoset与报文格式之间的桥梁 WCF自带了三种编码器（.NET框架3.0） 文本，MTOM，二进制 .NET框架3.5引入了JSON编码器 通常应互操作性的要求来决定使用何种编码器 二进制编码速度快，但不具备互操作性 MTOM用于大量的二进制数据，同时具备互操作性 文本编码则可满足大部分互操作性的要求,编码器总结,二进制编码显著快于文本编码 可同时提供一个可互操作的端点和一个不可互操作的端点 MTOM与二进制编码相近 消息越大，编码器对性能的影响也越大 协议本身的开销与实际吞吐量相比可以忽略不计 消息越小，编码器对性能的影响也越小 大部分时间耗费在协议本身,吞吐量（已规格化）,演示,序列化器与编码器,葛子昂 软件设计工程师 微软中国研发集团,日程,回报 传输层，序列化器，及编码器 客户端的选项 服务端的选项 流传输 通常的建议,WCF客户端/代理的基础,Svcutil.exe可以为服务创建一个代理类型 该类型实现了IClientChannel 实例化该类型需要额外的开销 还可以使用ChannelFactory 应该使用哪一个？ Svcutil.exe创建的类型易于使用，但开销较大 ChannelFactory不易使用，但开销较小 经常被误用！,客户端/代理总结,销毁不用的代理 会达到阈值：可能会导致客户端挂起 会耗尽资源：如套接字 不要在每次调用时都创建一个新的代理 如果信道是有状态的，那么可以重复使用ChannelFactory “Increasing Middle-Tier Client Performance” http:/msdn2.microsoft.com/en-us/library/aa738757.aspx 如果进行缓存，那么还要考虑对伸缩性的影响 异步，异步，异步！,代理的吞吐量,演示,客户端的使用,葛子昂 软件设计工程师 微软中国研发集团,代码：在代理内进行缓存,日程,回报 传输层，序列化器，及编码器 客户端的选项 服务端的选项 流传输 通常的建议,服务基础,服务是异步的 不要浪费CPU资源 ServiceModel做了一些保守的限制 MaxConcurrentSessions = 10 MaxConcurrentCalls = 16 InstanceContext被设定为PerCall 考虑同步的开销 绑定指定了闲置超时 ReceiveTimeout：可防御客户端不及时关闭连接,演示,服务的使用,葛子昂 软件设计工程师 微软中国研发集团,日程,回报 传输层，序列化器，及编码器 客户端的选项 服务端的选项 流传输 通常的建议,流传输的基础,大型数据的传输 经验法则：当数据量大于1M时考虑使用流 只能用于HTTP，TCP和NamedPipe传输层 既可传入服务，也可从服务中传出，或双向 设定绑定的TransferMode.Streamed 在契约中使用System.IO.Stream 设定MaxReceivedMessageSize 默认设定为64k,流传输的调控,Windows和WCF会对内容进行缓存 即便是流传输的情况下也是如此 WCF提供了用Nagle算法来控制缓存的支持 ConnectionBufferSize 指定本地缓存的大小 MaxOutputDelay 在本地缓存数据的最长时间 AllowOutputBatching 在WCF内部启用批处理,演示,流传输,葛子昂 软件设计工程师 微软中国研发集团,日程,回报 传输层，序列化器，及编码器 客户端的选项 服务端的选项 流传输 通常的建议,常见的陷阱,不销毁无用的代理 每次调用都创建一个新的代理 在没有必要的时候启用安全性（Web） NetTcp/NetPipe/WSHttp默认情况下开启 使用ServerThrottle的默认设定 MaxConcurrentSessions = 10 MaxConcurrentCalls = 16 契约中使用了流传输，而绑定中却仍然使用缓存 必要时采用流传输：内存的使用，较大的负荷 负荷较小时采用缓存更快,可用的工具,SvcConfigEditor：可方便地显示所有设定 SvcTraceViewer：对追踪数据进行诊断 性能计数器 Visual Studio Team Suite中的性能工具 Netmon：可分析线上的数据及其行为 3.1版已开放下载http:/blogs.technet.com/netmon ETW (Xperf) http:/msdn2.microsoft.com/en-us/library/aa363668.aspx http:/www.storage-developer.org/events/storage-developer2007/presentations/BWorthington_Capturing_Comprehensive_Storage_Workload.pdf,最佳实践,不要猜想：测量！ 实际负荷具有很大的影响 部署会造成很大的差异 其它应用程序争夺资源 网络拓朴可能导致延迟 安全性（活动目录，x509 & CRLs） 对主要的用户场景从头至尾进行测量 若只对场景的某一部分进行测量，则一定要谨慎,性能调整检查表（1）,传输层 NetPipe, NetTcp, BasicHttp, WSHttp 代理 重用ServiceChannel，重用ChannelFactory. 安全性 传输层，WS-* +MessageCredentials，完全WS-* 编码器 文本编码，MTOM，二进制编码，JSON 压缩编码，非WCF自带（GZipStream）,性能调整检查表（2）,运行方式 自主运行，在IIS内运行 在Vista/2008 Server下，IIS7内运行时可支持NetTcp/NetPipe 限额/阈值 在提高限额/阈值的同时，使其保持尽可能地小 实例化/并发 Singleton/Multiple 事务 OleTx, WS-AT 队列 使用批处理,答惑解疑,Q&A,参考资源,A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies http:/msdn2.microsoft.com/en-us/library/bb310550.aspx,Increasing Middle-Tier Client Performance http:/msdn2.microsoft.com/en-us/library/aa738757.aspx,Netmon 3.0 http:/connect.microsoft.com,.NET StockTrader Sample Application http:/msdn2.microsoft.com/en-us/netframework/bb499684.aspx,ETW (Xperf) http:/msdn2.microsoft.com/en-us/library/aa363668.aspx http:/www.storage-developer.org/events/storage-developer2007/presentations/BWorthington_Capturing_Comprehensive_Storage_Workload.pdf,感谢您参与此会场！ 您的意见与建议对我们非常重要。请您填写反馈表。,