关于文件性能的两个问题:

我需要制作一个服务器来处理可能同时发生的数千个请求:

• 文件散列
• 文件压缩
• 解压文件
• 可能还有一些文件复制/移动

我无法控制客户的硬件(RAID 配置等)，所以我假设我所能做的就是请求数百个文件操作，并允许操作系统和磁盘 Controller 提供它们可以提供的任何优化。正确吗？

下一个问题:我想最大限度地使用 I/O 完成线程(而不是工作线程)。我认为我唯一可以通过 .net 3.5 获得的是通过“BeginRead/Write”提供的:

• System.IO.Compression.DeflateStream
• System.IO.Compression.GZipStream
• System.IO.FileStream
• 系统.IO.流

我是否遗漏了一些可以让我能够使用 I/O 完成线程来散列文件的东西？ 7Zip SDK 是否使用 I/O 完成线程？

最佳答案

首先，虽然 .NET 在性能方面相当不错，但如果非常高的性能是基本要求，我会转向 native 编译的非托管语言，如 C++。 JIT 编译和 CLR 的其他开销将降低用 .NET 编写的任何算法的性能。

我认为数千个真正同时发生的请求将表明一个高度分布式的模型；现在，市场上最好的服务器硬件(双 Xeon 四核超线程 CPU)一次只能做 32 件事，监听做事的请求、与硬件层对话以及其他一般操作系统/运行时开销将占用其中几个。我会分析您希望此服务器同时处理的实际流量，并缩放您在其上工作的盒子数量以匹配。

其次，当你说“I/O 完成线程”时，我认为你是在谈论异步 Begin/End 调用用来完成其工作的线程，而不是来自 ThreadPool 的线程(避免在真正的线程中- 繁重的应用程序)或用户创建的线程(这些没问题，只需注意您的线程数)。实际上，除了少数特殊情况，一个线程就是一个线程，它的生成位置在硬件级别上并没有太大区别，所以如果你真的想要，生成使用同步调用的工作线程会让你很漂亮结果大致相同(但通常使用现有工具比伪造新工具更好)。

现在，回答您真正的问题。不，没有用于散列的异步模型；如果要对散列操作进行多线程处理，则必须单独生成线程。但是，散列需要一个流或字节缓冲区，可以使用 Stream.BeginRead() 异步获取，传递给 BeginRead() 的回调方法可以在异步调用生成的线程中执行散列。

https://stackoverflow.com/questions/3816643/