前言：
并发模型你们会想到什么来操作呢，是不是很高大上这个词语
我们测试常见跟开发人员接口或者并发问题，对我们测试很苦脑有没有？
记得我刚进测试的时候也是小白一个，做功能一直点点点，然后开发人员说测试一下压力测试
然后大家就是用工具来进行测试，这样的方法是可能进行测试，如果开发人员就给了你一个链接，什么都没有给，你们会在心理说，这怎么能做并发呢，没有参数这是我们测试脑袋中第一时间说的话，但很多公司就是这样，就告诉你在那里自己做，我们就要写异步脚本，对性能工具少一点依赖，我们用的最多听得最多就是Jmeter，SoupUI,LoadRunner等等
现在就给大家举个例子：
最简单的并发线程
import socket
response = ‘HTTP/1.1 200 OK\r\nConnection: Close\r\nContent-Length: 11\r\n\r\nHello World‘
server = socket.socket()
server.bind((‘x.x.x.x‘, xxxx))
server.listen(1024)
while True:
client, clientaddr = server.accept()
request = client.recv(1024)
client.send(response)
client.close()
访问localhost:xxxx，返回“Hello World”
如果你用ab进行测试性能数据
ab -n 10000 -c X http://localhost:xxxx/
Time taken for tests: 2.1234 seconds
发送1万个请求，X（我的CPU核数为X）个请求同时并发，耗时2.1234秒。
性能瓶颈在哪里呢？就在上面的两个半阻塞。
accept和recv是完全阻塞的，而为什么send是半个阻塞呢？
在内核的 socket实现中，会有两个缓存 (buffer)。read buffer 和 write buffer 。当内核接收到网卡传来的客户端数据后，把数据复制到 read buffer ，这个时候 recv阻塞的进程就可以被唤醒。
当调用 send的时候，内核只是把 send的数据复制到 write buffer 里，然后立即返回。只有 write buffer 的空间不够时 send才会被阻塞，需要等待网卡发送数据腾空 write buffer 。在 write buffer的空间足够放下 send的数据时进程才可以被唤醒。
如果一个请求处理地很慢，其他请求只能排队，那么并发量肯定会受到影响。
后面多讲一下理论课，并发要知道那些才能进行测试
1.线程
2.进程
3.远程分布式主机
4.伪线程