使用批处理、异步和并行计算开发高性能分布式应用程序

• 下载源文件 - 1002 Kb

引言

我自 2001 年以来一直在致力于创建基于原始套接字的批处理、异步和并行计算框架。2002 年，我发表了题为《使用免费 SocketPro 包创建超级客户端和服务器应用程序》的文章，并将我的想法 在此 处发布。之后，我花了大量时间改进该软件包。目前，该框架在 Win32 平台下已经成熟并完成。该框架具有许多吸引人的特性。本文重点关注性能比较。众所周知，软件性能在实际企业系统中至关重要。没有哪个软件工程师愿意创建 sluggish 的软件。本文附带所有源代码，专门向您展示该框架与最新的 Microsoft 技术 .NET Remoting 相比的性能提升。希望它能引起您的注意。

安装

本文提供了示例客户端-服务器项目，以帮助您尝试 .NET Remoting 和 SocketPro。首先，您需要确保客户端和服务器计算机上都安装了 MS .NET Framework 1.1 版本并能正常运行。其次，您需要设置 MSDE 或 MS SQL Server，并包含示例数据库 Northwind。之后，请为客户端和服务器执行以下设置。

客户端设置 -- 注册两个 COM DLL

找到命令提示符，导航到包含两个 COM DLL usocket.dll 和 udb.dll 的目录，然后通过执行以下命令注册这两个 DLL

• Regsvr32 usocket.dll
• Regsvr32 udb.dll

服务器设置

找到可执行文件 DotNetSvrOne.exe，并通过双击启动它。您就可以开始尝试示例项目了。

要查看源代码，请参阅目录 ..\sourcecode，其中包含 udb.dll 和 SocketAroAdapter.dll 的源代码。此外，您还可以在目录 ..\source code\offsetclient 和 ..\source code\offsetserver 中找到客户端和服务器的示例代码。请注意，udb.dll 是使用 Visual C++ 和 ATL/COM 编写的。如果您想查看此 DLL 中的代码执行，您必须具备一些关于 Visual C++ 用法的基本知识。

.NET Remoting 示例使用 TCP 二进制格式通道和 UTF-8 编码创建。

实验硬件条件

下一节中的性能数据是在以下硬件配置下获得的

• 服务器：单处理器/P IV 1.9 GHz，512 MB 内存，MS XP Professional。
• 客户端：单处理器/P IV 1.9 GHz，512 MB 内存，MS XP Professional。

结果

以下数据是通过使用不同的网络获得的，包括慢速拨号调制解调器、10 Mbps LAN 和 100 Mbps LAN。此外，我还列出了在同一台机器（Localhost）上处理不同应用程序之间请求的测试结果。

测试结果包括查询不同大小的行集和执行 10000 次回显请求。请参见下表中第一列。毫秒为单位的所需时间是指 .NET Remoting 处理请求所需的时间。使用 SocketPro 处理类似请求所需的时间可以通过将所需时间除以一个因子来找到。例如，将 Products 表从 .NET Remoting 服务器带到客户端所需的时间为 48.9 毫秒。相比之下，SocketPro 所需时间仅为 8.9 毫秒（48.9/5.5）。因此，下表中的因子实际上代表了 SocketPro 相对于 .NET Remoting 的速度提升。测试旨在研究不同行集大小对 .NET Remoting 和 SocketPro 性能的影响。请参见表中第 2 列和第 3 列的数据。有关表架构的详细信息，请参见使用 Access 或 SQL Server 的 MS 示例数据库 Northwind。

总的来说，上表中的结果清楚地表明，在所有情况下，SocketPro 相对于 .NET Remoting 都具有巨大的性能优势。

LAN（本地区域网络）

1. 微小行集（130% - 250%）

   对于微小的行集（例如 Shippers），SocketPro 大约比 .NET Remoting 快 90%（30% - 150%）。

2. 小型行集（400% - 700%）

   对于小型表（例如 Products），SocketPro 的速度通常是 .NET Remoting 的五倍（300% - 600%）。

3. 常规行集（1000% - 3000%）

   如果您必须处理一个正常大小的行集，如上表所示的 Order Details 和 Orders 表，SocketPro 的速度可以轻松超过 .NET Remoting 的二十倍。

4. 大型行集（> 3000%）

   对于大型行集，例如“select * from orders, products”生成的行集（列数为 (14+10)，行数为 63910 行（830*77），不算太大），SocketPro 比 .NET Remoting 快 3500% 或更多。 .NET Remoting 的内存占用约为 400 MB RAM，开销约 90 秒。SocketPro 的开销仅为 0.01 秒，内存占用仅为 5 MB RAM。

正如这些测试数据所暗示的那样，行集越大，因子越大。这表明当涉及大型行集时，SocketPro 的速度远远快于 .NET Remoting。

我还分析了导致 .NET Remoting 性能低下的原因。发现在一端将 DataSet 对象序列化为流，以及在另一端将流反序列化为 DataSet 对象时，.NET Remoting 的性能都很差。序列化和反序列化中的每一个都需要大约 42 秒。将 DataSet 流从服务器发送到客户端相对快速高效，在 100 Mbps 网络上仅需几秒钟。此时，一个 DataSet 对象被打包到一个大的文本流中，跨越了两个应用程序域。将二进制数据转换为文本，然后转换为一个大的流，开销过大。相反，SocketPro 以批处理方式打包行集，而不是一个大的流。此外，由于其异步计算，在一次序列化行集到流以及另一次反序列化流到行集可以同时进行。在线压缩功能对于低带宽网络非常有益。这三个 SocketPro 关键功能确保了其超高性能。

尽管 Microsoft 未来可能会以二进制格式打包 DataSet，但 .NET Remoting 仍然会很慢，因为将 DataSet 对象序列化和反序列化为一个大的流会占用过多内存。在运行时占用过多内存总是会降低应用程序的性能，尽管与当前打包 DataSet 对象的方法相比会有所改善。

简单请求（约 1000%）

我还使用 SocketPro 和 .NET Remoting 分别执行了 10000 次回显请求。如上表所示，两者之间的差异约为 10 倍。SocketPro 可以将许多请求进行批处理，并将它们通过单个流发送到远程机器。这个关键功能总是能极大地改善您的分布式应用程序。这是 SocketPro 的一项吸引人的功能。

WAN（广域网）

我还比较了 SocketPro 与 .NET Remoting 在具有长延迟的慢速网络（拨号连接）上的性能。SocketPro 与 .NET Remoting 之间的性能差异巨大。请参见上表中的数据。SocketPro 已集成在线压缩功能。我们的实验已证实，该功能对于带宽低于 50 Mbps 的所有网络都非常有益。该功能通常可将 Unicode 字符串的打包性能提高三倍，对于其他原始数据类型的打包性能至少提高一倍。如果您必须通过昂贵的网络（如拨号、DSL、电缆和无线调制解调器）向远程服务器发送多个请求，SocketPro 的批处理功能将极大地提高应用程序性能（高达 200 倍或更多）。考虑到慢速网络的长期延迟，SocketPro 相对于 .NET Remoting 的改进如此之大，以至于您无法简单地忽略它！

与 SocketPro 相比，.NET Remoting 的运行速度确实像蜗牛一样慢，无论您使用什么网络，也无论处理什么对象或请求。我很抱歉，微软和 .NET Remoting 的专家们，但这确实是一个事实。

结论

SocketPro 是通过异步、批处理和并行计算编写的。其设计与 SOAP/XML Web 服务、.NET Remoting、DCOM、CORBA 和 Java RMI 等框架截然不同。它更接近于非阻塞套接字，但它无疑使套接字编程更加容易。本文专门用于演示 SocketPro 的性能，并与 MS .NET Remoting 进行了比较。尽管我没有将其与其他常见框架进行比较，但可以保证，与其他框架相比，它们的速度都会像蜗牛一样慢。SocketPro 因其以下关键功能而提供卓越的性能

1. SocketPro 可以在客户端批处理任意数量的请求，并在服务器端返回结果，从而实现 100% 的网络效率，不浪费带宽。这与上述常见框架有很大不同。
2. SocketPro 的在线压缩通常可将性能再提高 2-3 倍。在某些情况下，提高幅度可能超过十倍。
3. SocketPro 完全利用了通过昂贵网络传输二进制数据。它不使用文本格式在网络上移动数据。
4. SocketPro 使用 100% 的非阻塞套接字通信，因此在一个事务循环中的所有网络设备都可以并发工作，而上述常见的同步框架则无法确保在一个事务循环中的所有网络设备都能同时工作。

我不期望 .NET Remoting 在任何情况下都能在性能上与 SocketPro 相匹配，无论您拥有何种机器和网络。如果您发现 .NET Remoting 能够提供类似性能的情况，请在此处或私下告知我。