Real-time web features require a long-lived mostly-idle connection per user. In a traditional synchronous web server, this implies devoting one thread to each user, which can be very expensive.
Web系统的实时性要求，为每个用户保持一个连接，这些连接大多时间是空闲的。在传统的同步web服务器中，即是为每个用户分配一个线程，这种做法相当耗费资源。
那么什么是同步/异步、阻塞/非阻塞呢？
异步（Asynchronous）和非阻塞（non-blocking）是紧密相关的两个术语，也经常被不加区分使用。但实际它们是不同的概念。
当一个方法在返回前等待某件事情，那么它就被阻塞了。引起阻塞的事情可以是network，可以是IO，也可以是CPU。实际上，任何一个方法都或多或少的被阻塞，因为只要运行就需要CPU。
而我们常说的阻塞/非阻塞，通常是从某一个方面来看的。比如非阻塞的http请求（发送即返回，不等待响应），在域名解析时仍然是阻塞的，只不过这类阻塞从整体上来看影响是非常小的。
而异步说的是，一个方法在执行结束前就返回了，一般会在后台产生一些工作并在未来某一时刻触发一些动作。与之相对应的同步，就是说在方法返回前，要把所有的事情做完。
好吧，还是觉得很难区分。。。不过这不重要，知道是这么一回事就可以了。
来一个例子：
餐厅来了10个顾客，为了提供最佳消费体验，不让顾客等待，为每个顾客分配一个服务员。服务员给顾客安排好座位，把菜单交给顾客，然后在一边等待顾客点餐。点完餐后把订单交给厨房，然后在厨房等待大厨烹饪。菜做好后，将菜送到桌上，然后在桌旁静静的看着顾客吃。。。
这就是同步，为了保证“实时”的服务，需要有一个专门的人员时刻等待。
有人说了，这尼玛不是有病么！哪个餐厅这么干？可是传统的web服务器就是这样的呢，比如apache。
现实中的餐厅为了节省成本，当然不会这么做，也许两个服务员就足够了。给新进来的顾客安排好座位，菜单交给他，然后就可以去忙活其他的顾客了。等顾客点好菜喊一声，赶紧冲过来下单。。。
这就是前文所说的异步方式，服务员不需要等待顾客完成全部任务，就“返回”了。
那有这种方式的web服务器么？当然有了，也是近年来的新趋势，如nginx、tornado等。
又有人说了，这和我们的主题压力测试又有什么关系呢？
我们以往所做的压力测试，一般是要通过一些工具来模拟压力（多用户），比如LoadRunner, Jmeter等，也都是采用这种同步的方式。测试工程师负责写脚本来定义“一个”用户的行为，工具会启动多个线程执行脚本，每个线程只负责自己的脚本（一个用户）。
在测试脚本中，描述了一个用户的典型操作。比如访问一个网址，提交一些数据，等待返回的响应，然后可能还要休息一段时间（ThinkTime）再做下一次操作。
实际上，一个线程在执行脚本的过程中，绝大多数时间都是在等待的，等待服务器响应，以及主动的sleep模拟真实用户的操作间隔。
可以看到，同步方式最大的问题就是浪费资源。一万个用户需要一万个线程，一万个线程需要几台机器才能运行呢？
既然这么多线程都在等待，难道不能用更少的线程么？在一个用户等待的时间，去处理其他用户的事情？
这正是这个系列文章要探索的内容——采用异步的方式来做压力测试。
敬请期待！
ps.
时隔三年，再一次更新博客。
这三年，经历了创业团队，也怀疑过未来的方向。
最终在给自己放了半年长假后，选择回归这个领域。