实现一个高性能的服务应用依赖于一个高性能的线程模型。线程太多或太少都会引起性能问题。举一个极端的例子，如果一个服务只用一个线程处理所有的用户请求，性能会很糟糕，因为受限于一个线程同一时间只能处理一个请求。当然，一个线程是可以同时处理多个请求的，需要I/O的时候就切换，但是这样会引入具大的复杂性并且也不能利用好电脑的多个cpu。另一个极端是，服务创建一个大的线程池，可以让每个请求对应一个单独的线程。这会导致线程抖动问题。大量线程被唤醒，做一些cpu操作，然后阻塞在I/O上，处理完成后，再阻塞以等待下次请求。如无意外，调度器会分隔cpu 时间，并引起上下文切换。
我们的目标是，尽量避免线程阻塞，尽可能少的引起上下文切换，同时最大化利用多个线程的并发机制。理想情况是，每一个cpu都有一个线程处理用户请求，当这些线程处理完请求后不阻塞因为刚好有等待的请求需要处理。如果想让电脑按我们设想的工作，必须有一套机制，当一个线程因为一个用户请求被阻塞在I/O上的时候，激活另一个线程。
Windows NT 3.5 介绍了一些api可以使我们相对简单的完成这个任务。这些API围绕着一个对象叫做completion port 。在这篇文章中，我会概述completion port如何使用，以及Windows实现他们的底层原理。
应用利用completion port 作为多个文件操作符I/O完成时的焦点。当一个文件和一个completion port对应起来的时候，任何异步I/O操作完成，会以队列的方式发一个completion包给这个port。所以一个线程可以简单的等待多个文件操作完成。只要适当的控制线程的数量，就可以发挥系统最大的性能。
当应用创建一个completion port的时候，会指定一个并发值。这个值是completion port对应的最大的可以及时的运行的线程数。像我之前描述的那样，最理想的是同一时间一个线程对应一个cpu。这个并发值被windows用来控制多少个线程可以被激活，如果活跃的线程已经等于这个并发值了，那么windows将不会再允许completion port再多个线程运行。一个线程处理处理完成一个请求，然后检查一下队列里有没有completion包，如果有就处理，这个过程中，没有上下文切换。
completion port的工作流见下图
原文见
http://sysinternals.d4rk4.ru/Information/IoCompletionPorts.html
