关于文件性能的两个问题：
我需要创建一个服务器来处理潜在的数千个并发请求：
我无法控制客户的硬件（RAID 配置等），所以我认为我所能做的就是请求数百个文件操作，并允许操作系统和磁盘控制器提供他们可以提供的任何优化。对吗？
下一个问题：我想最大限度地利用 I/O 完成线程（而不是工作线程）。我认为唯一可以通过 .net 3.5 获得的，是通过“BeginRead/Write”提供的：
我是否缺少某些东西可以使我能够使用 I/O 完成线程来散列文件？ 7Zip SDK 是否使用 I/O 完成线程？
【问题讨论】：
标签： .net performance file compression
首先，虽然 .NET 在性能方面相当不错，但如果高性能是基本要求，我会转向像 C++ 这样的本机编译的非托管语言。 JIT 编译和 CLR 的其他开销将降低任何用 .NET 编写的算法的性能。
我认为数以千计的真正同时请求将表明一个高度分布式的模型；目前，市场上最好的服务器硬件（双 Xeon 四核超线程 CPU）一次只能做 32 件事情，并且监听做事情的请求、与硬件层对话以及其他一般的操作系统/运行时开销了其中的几个。我会分析您希望此服务器同时处理的实际流量，并调整您在其上工作的盒子数量以匹配。
其次，我认为您所说的“I/O 完成线程”是异步 Begin/End 调用用来完成其工作的线程，而不是来自 ThreadPool 的线程（避免在真正的线程中- 繁重的应用程序）或用户创建的线程（这些没问题，只需注意您的线程数）。真的，除了一些特殊情况，线程就是线程，它的确切生成位置在硬件级别上并没有太大的区别，所以如果你真的想要，生成使用同步调用的工作线程会让你很漂亮结果大致相同（但通常最好使用现有工具而不是伪造新工具）。
现在，回答你真正的问题。不，没有用于散列的异步模型；如果要对哈希操作进行多线程处理，则必须单独生成线程。但是，散列需要流或字节缓冲区，可以使用 Stream.BeginRead() 异步获取，传递给 BeginRead() 的回调方法可以在异步调用产生的线程中执行散列。
【讨论】：
我建议研究 F# 中的新异步编程模型。 Luke Hoban 在新奥尔良举办的 MS TechEd 2010 上有一段关于这个主题的精彩视频：
【讨论】：