并发连接数、请求数、并发用户数

概念

并发连接数-SBC(Simultaneous Browser Connections

并发连接数指的是客户端向服务器发起请求,并建立了TCP连接。每秒钟服务器链接的总TCP数量,就是并发连接数。

请求数-QPS(Query Per Second)/RPS(Request Per Second)

请求数有2个缩写,可以叫QPS也可以叫RPS。单位是每秒多少请求。Query=查询,也相当于请求。请求数指的是客户端在建立完连接后,向http服务发出GET/POST/HEAD数据包,服务器返回了请求结果后有两种情况:

  • http数据包头包含Close字样,关闭本次TCP连接;
  • http数据包头包含Keep-Alive字样,本次连接不关闭,可继续通过该连接继续向http服务发送请求,用于减少TCP并发连接数。

服务器性能怎么测?

通常情况下,我们测试的是QPS,也就是每秒请求数。不过为了衡量服务器的总体性能,测试时最好一起测试并发连接数和请求数。

测试原理

  • 测试并发连接数采用每个并发1请求,多个并发进行;
  • 测试请求数采用多并发、每个并发多个请求进行,总的请求数将会=并发数*单并发请求数,需要注意的是不同的并发和单并发请求数得出来的结果会不同,因此最好测试多次取平均值。

区分请求数意义何在?

大家打开Chrome浏览器,按下F12,切换到Network选项卡,随便打开一个网页,按下F5刷新,将会看到刷刷一堆的请求。这里给出某大牛收集来的不同浏览器产生的单站点并发连接数:

浏览器 HTTP 1.1 HTTP 1.0
IE 6,7 2 4
IE 8 6 6
Firefox 2 2 8
Firefox 3 6 6
Safari 3, 4 4 4
Chrome 1,2 6 ?
Chrome 3 4 4
Opera 9.63,10.00alpha 4 4

以Chrome为例,假设服务器设置的是Close(非持久连接),浏览器打开网页后,首先打开4个并发加载数据,在这些请求完成后关闭4个连接,再打开4个并发连接加载数据。也就是说,并不是这个网页有100个请求就会产生100并发,而是4个并发连接并行。假设服务器设置的是keep-alive(持久连接),浏览器打开网页后,首先打开4个并发加载数据,在这些请求完成后不关闭连接,而是继续发出请求,节约重新打开连接的时间。【前面红色标出的是keep-alive持久连接和close非持久的区别,持久连接除了Squid(这货用了特殊方法在http 1.0实现持久连接),只在http 1.1协议中有效!】

主机到底能多少人在线?

看到这里相信你已经知道答案了,这个问题无解,根据网页的内容大小和单网页的请求数和服务器的配置而定,这个数据的浮动值非常大所以无法测量。因此能承诺保证多少用户在线就是坑爹的主机商!

并发用户

并发用户数量,有两种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的全部用户的数量,理由是这些用户可能同时使用系统;还有一种比较接近正确的观点是把用户在线数量理解为并发用户数量。实际上,在线用户不一定会和其他用户发生并发,例如正在浏览网页的用户,对服务器是没有任何影响的。但是,用户在线数量是统计并发用户数量的主要依据之一。
并发主要是针对服务器而言,是否并发的关键是看用户操作是否对服务器产生了影响。因此,并发用户数量的正确理解为:在同一时刻与服务器进行了交互的在线用户数量。这些用户的最大特征是和服务器产生了交互,这种交互既可以是单向的传输数据,也可以是双向的传送数据。
并发用户数量的统计的方法目前还没有准确的公式,因为不同系统会有不同的并发特点。例如OA系统统计并发用户数量的经验公式为:使用系统用户数量*(5%~20%)。对于这个公式是没有必要拘泥于计算的结果,因为为了保证系统的扩展空间,测试时的并发用户数量要稍微大一些,除非是要测试系统能承载的最大并发用户数量。举例说明:如果一个OA系统的期望用户为1000个,只要测试出系统能支持200个并发用户就可以了。

Nginx1.4支持SPDY了,但SPDY 是什么?如何部署 SPDY?

SPDY 是什么?如何部署 SPDY?
http://www.williamlong.info/archives/3119.html

Not as SPDY as You Thought[中译本]
http://www.oschina.net/translate/not-as-spdy-as-you-thought

Nginx添加SPDY的支持
http://nginx.org/patches/spdy/README.txt

SPDY 协议的优点

1. 多路复用 请求优化
SPDY 规定在一个 SPDY 连接内可以有无限个并行请求,即允许多个并发 HTTP 请求共用一个 TCP会话。这样 SPDY 通过复用在单个 TCP 连接上的多次请求,而非为每个请求单独开放连接,这样只需建立一个 TCP 连接就可以传送网页上所有资源,不仅可以减少消息交互往返的时间还可以避免创建新连接造成的延迟,使得 TCP 的效率更高。

此外,SPDY 的多路复用可以设置优先级,而不像传统 HTTP 那样严格按照先入先出一个一个处理请求,它会选择性的先传输 CSS 这样更重要的资源,然后再传输网站图标之类不太重要的资源,可以避免让非关键资源占用网络通道的问题,提升 TCP 的性能。

2. 支持服务器推送技术
服务器可以主动向客户端发起通信向客户端推送数据,这种预加载可以使用户一直保持一个快速的网络。

3. SPDY 压缩了 HTTP 头
舍弃掉了不必要的头信息,经过压缩之后可以节省多余数据传输所带来的等待时间和带宽。

4. 强制使用 SSL 传输协议
Google 认为 Web 未来的发展方向必定是安全的网络连接,全部请求 SSL 加密后,信息传输更加安全。

对于做B/S开发的同学来说,1和2,应该是最振奋人心的改进了,实现服务器推( 今天是2013-04,找了一些文档,Nginx 1.4的版本中还没有实现服务器推的功能?)应该能带来更好体验的web2.0应用,可以很好的解决ajax flush, server hold的性能瓶颈。

nginx+php-fpm 上传大文件的设置

大文件上传要注意几个环节
1,上传文件需要花费较长上传时间和处理执行时间,需要设置nginx上传时间、延攻php执行超时时间
2,大文件处理需要占用较大内存,需要增加php内存池,考虑到有多个文件上传处理的并发,这个内存建议根据并发相乘

以下为每个应用的相关配置

nginx的修改
send_timeout 60;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
client_max_body_size 30m;

php的修改
upload_max_filesize 500M
post_max_size 500M
max_input_time 300
max_execution_time 300

php-fpm注意参数
request_terminate_timeout
request_slowlog_timeout
这两个参数如果设置过小的话会导致文件传输了一部分后连接关闭。

举例如下:

2014/07/08 23:00:40 [error] 56794#0: *10350 upstream timed out (60: Operation timed out) while reading response header from upstream, client: 127.0.0.1, server: www.4wei.cn, request: "POST /uploadurl/ HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.4wei.cn"

由于后端执行时间超时(Operation timed out),超出了nginx的请求时间,需要延长fastcgi_read_timeout时间