同步和异步代码
　　class SyncSleepHandler(RequestHandler):
　　"""
　　同步的方式，一个延时1s的接口
　　"""
　　def get(self):
　　time.sleep(1)
　　self.write("when i sleep 5s")
　　class SleepHandler(RequestHandler):
　　"""
　　异步的延时1秒的接口
　　"""
　　@tornado.gen.coroutine
　　def get(self):
　　yield tornado.gen.Task(
　　tornado.ioloop.IOLoop.instance().add_timeout，
　　time.time() + 1
　　)
　　self.write("when i sleep 5s")
　　同步测试结果
　　?  /  ab -n 200 -c 40 http://localhost:8009/demo/syncsleep-handler/
　　This is ApacheBench， Version 2.3 <$Revision: 1528965 $>
　　Copyright 1996 Adam Twiss， Zeus Technology Ltd， http://www.zeustech.net/
　　Licensed to The Apache Software Foundation， http://www.apache.org/
　　Benchmarking localhost (be patient)
　　Completed 100 requests
　　Completed 200 requests
　　Finished 200 requests
　　Server Software:        TornadoServer/4.2.1
　　Server Hostname:        localhost
　　Server Port:            8009
　　Document Path:          /demo/syncsleep-handler/
　　Document Length:        15 bytes
　　Concurrency Level:      40
　　Time taken for tests:   200.746 seconds
　　Complete requests:      200
　　Failed requests:        0
　　Total transferred:      42000 bytes
　　HTML transferred:       3000 bytes
　　Requests per second:    1.00 [#/sec] (mean)
　　Time per request:       40149.159 [ms] (mean)
　　Time per request:       1003.729 [ms] (mean， across all concurrent requests)
　　Transfer rate:          0.20 [Kbytes/sec] received
　　Connection Times (ms)
　　min  mean[+/-sd] median   max
　　Connect:        0    0   0.2      0       1
　　Processing:  1005 36235 18692.2  38133  200745
　　Waiting:     1005 36234 18692.2  38133  200745
　　Total:       1006 36235 18692.2  38133  200746
　　Percentage of the requests served within a certain time (ms)
　　50%  38133
　　66%  38137
　　75%  38142
　　80%  38161
　　90%  38171
　　95%  38176
　　98%  38179
　　99%  199742
　　100%  200746 (longest request)
　　异步测试结果
　　?  /  ab -n 200 -c 40 http://localhost:8009/demo/sleep-handler/
　　This is ApacheBench， Version 2.3 <$Revision: 1528965 $>
　　Copyright 1996 Adam Twiss， Zeus Technology Ltd， http://www.zeustech.net/
　　Licensed to The Apache Software Foundation， http://www.apache.org/
　　Benchmarking localhost (be patient)
　　Completed 100 requests
　　Completed 200 requests
　　Finished 200 requests
　　Server Software:        TornadoServer/4.2.1
　　Server Hostname:        localhost
　　Server Port:            8009
　　Document Path:          /demo/sleep-handler/
　　Document Length:        15 bytes
　　Concurrency Level:      40
　　Time taken for tests:   5.083 seconds
　　Complete requests:      200
　　Failed requests:        0
　　Total transferred:      42000 bytes
　　HTML transferred:       3000 bytes
　　Requests per second:    39.35 [#/sec] (mean)
　　Time per request:       1016.611 [ms] (mean)
　　Time per request:       25.415 [ms] (mean， across all concurrent requests)
　　Transfer rate:          8.07 [Kbytes/sec] received
　　Connection Times (ms)
　　min  mean[+/-sd] median   max
　　Connect:        0    0   0.4      0       2
　　Processing:  1001 1010  12.0   1005    1053
　　Waiting:     1001 1010  12.0   1005    1053
　　Total:       1001 1010  12.3   1005    1055
　　Percentage of the requests served within a certain time (ms)
　　50%   1005
　　66%   1009
　　75%   1011
　　80%   1015
　　90%   1032
　　95%   1044
　　98%   1045
　　99%   1054
　　100%   1055 (longest request)

　　结果对比
　　在并发量为40，总请求量为200的简单的压力测试里面，两种网络IO模型的编程方式的性能对比如下：
　　同步和异步性能对比
　　性能指标 同步阻塞式 异步非阻塞式
　　每秒处理请求数（Requests per second） 1 39
　　请求平均等待时间-ms（Time per request，mean） 40149 1017
　　请求平均处理时间-ms（Time per request，across all ） 1003 25
　　测试的结果比较符合被测试程序的理论预期，因为被测试程序就功能就是：一个1s的延时等待。
　　显然：异步非阻塞式 和性能是远高于 同步阻塞式 的。
　　在上表中的 同步IO模型 数据里：只要是进入了单个请求的处理环节，进入到睡眠等待的 内核态 操作时，就会将整个进程给 阻塞，别的程序就只能进入 等待 状态了，这样本质上还是使用的 串行 的处理方式，所以 请求平均处理时间 大概是1000ms（1秒）左右，然后完成一个并发度为40的请求平均等待时间为40149ms。
　　关于上面参数的理解可以进行简单的类比解释。
　　以如下场景为例子：客户去银行处理业务的窗口办理业务。
　　并行度：银行开设的服务窗口数和前台服务员
　　对应CPU，窗口数对应着核心数，即真正的实现并行的能力，即不是在时间分片后交错进行的 “假象并行”
　　并发度：大厅里面所有服务窗口等待服务的人数
　　对应着单次的并发度，即本次作业需要处理的任务量
　　总请求量：从银行大厅外面陆续过来加入到大厅队伍的客户的累计人数
　　内核态操作：银行业务中必须只能由前台服务员处理的操作
　　用户态操作：客户自己要处理的工作，比如：准备好自己的身份证，到外面复印证件，打电话和公司同事确认信息等等。
　　那么关于 同步 和 异步 的概念类比如下：
　　同步阻塞系统：银行 没有 排队叫号系统 ，客户（Web服务器进程） 只能 在队伍人群里面傻等轮到自己，没有在排队时间干其它事的机会。随着外面的人不断地进入大厅，新请求的每个人都要等前面的队伍的全部处理完毕后（ 40149ms）才能等到业务员（CPU）花1003ms 来处理自己的业务
　　异步非阻塞系统：银行 有 排队叫号系统 ，客户有可以 不用 在拥挤的人群中傻等，旁边的休息区打开处理其它事情。客户直接领取叫号单据，花掉 5ms 递交准备材料（发起内核态操作请求） 要么收发邮件，要么看下小电影，然后等叫号系统叫自己后，立刻上去 20ms的时间解决掉问题。客户实际浪费在这上面的时间为 25ms ，当然银行业务员（CPU）还是要花 1000ms 去处理这个任务的
　　在这个假设的场景里面，不管是同步还是异步，业务员（CPU）都是 满负荷 的工作，但是却极大的节省了客户（web服务器进程） 的时间。这样客户自身可以把等待业务员响应的时间都利用起来做一些其它工作，这样就极大地提高了整体的工作效率。
　　众所周知，python有GIL，所以多线程其实是伪多线程。tornado于是就单进程只用单线程，不做线程切换，但是又要实现并行的方式，就全部使用异步了。只要是某个请求进入了内核态的耗时的IO操作，tornado的主进程在发起内核IO初始化之后就做不管它了，立刻回到web的监控中来去响应别的请求。等内核态的IO完成之后，再回调到用户态的主进程处理结果。如果是用同步模型，如果是使用单进程多线程，则会造成线程切换的开销，如果使用单进程单线程（像django一样），如果有一个请求比较耗时，第二个人的请求只会排队等候的，Web服务进程绝大多数情况都是被阻塞状态，性能就极大地降低了。
　　最后结合前面的延时1s的例子，再加一个即时响应的接口示例：
　　class JustNowHandler(tornado.web.RequestHandler):
　　def get(self):
　　self.write("i hope just now see you")
　　有兴趣的同学可以自己做实验。 事先约定：
　　同步延时1s的接口为：A
　　异步延时1s的接口为：B
　　即时响应的接口为：C
　　使用单核模式运行web服务器。
　　然后在浏览器中以不同的顺序组合运行程序请求接口：
　　先即时再延时
　　先C再A：总共是1s后响应完毕C和A，C立刻响应
　　先C再B：总共是1s后响应完毕C和B，C立刻响应
　　先延时再即时
　　先A再C：总共是1s后响应完毕C和A，C必须等A处理完毕后，才能在1s后响应
　　先B再C：总共是1s后响应完毕C和B，C能立刻响应
　　同步模型中，一旦进程被阻塞掉，那么程序的效率就被等待的时间给严重降低了。
　　总结
　　有兴趣的同学，可以更深入的研究一下 《Unix网络编程-卷1，套接字联网API》（W.Richard Stevens） 的第6章第2节 I/O模型。
　　在python的web框架里面，tornado就是采用的最高效的异步非阻塞框架，可以在python语言下提供高性能的web应用服务。