并发测试开端

标签：listen   第一时间   瓶颈   alt   port   neu   load   方法   简单   

前言：

并发模型你们会想到什么来操作呢，是不是很高大上这个词语

我们测试常见跟开发人员接口或者并发问题，对我们测试很苦脑有没有？

记得我刚进测试的时候也是小白一个，做功能一直点点点，然后开发人员说测试一下压力测试

然后大家就是用工具来进行测试，这样的方法是可能进行测试，如果开发人员就给了你一个链接，什么都没有给，你们会在心理说，这怎么能做并发呢，没有参数这是我们测试脑袋中第一时间说的话，但很多公司就是这样，就告诉你在那里自己做，我们就要写异步脚本，对性能工具少一点依赖，我们用的最多听得最多就是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.伪线程

。。。。。。。。。。

并发测试开端

标签：listen   第一时间   瓶颈   alt   port   neu   load   方法   简单   

原文地址：http://www.cnblogs.com/yianketang/p/7385396.html