看你的这个图vuser数量在大致8min至12min内維持着最大数量，
但是你看每秒点击数在很早的时候，5min不到就已经基本稳定了，这似乎说明vuser已经被阻塞在了服务器的队列里面得不箌及时处理，服务器能处理的请求已经达到了极限
一旦这个指标的极限早于vuser数量的极限出现，就要怀疑服务器端的IIS是否做了保护而且保护得太紧了，服务器也许还有更大的处理能力但被限制了；
所以响应时间与vuser的吻合就很好解释了，但是也看不出来什么东西了
同理，吞吐量也因为这个原因看不出来什么东西，应该不是像你描述的“上不去了”
建议你看一下服务器端的配置，把那个保护放开再紦压力压上去看看
你对这个回答的评价是？
下载百度知道APP抢鲜体验
使用百度知道APP，立即抢鲜体验你的手机镜头里或许有别人想知道的答案。
横式采样器倒水样前应稍停片刻，以（）仪器外部带水混入水样 A、先让。 B、使 C、利于。 D、防止 横式采样器取样，必须在口门（）再提升仪器 A、通流时。 B、敞开時 C、关闭后。 D、关闭前 聚磷酸盐缓蚀剂属于（）。 A、有机缓蚀剂 B、阳极缓蚀剂。 C、阳极缓蚀剂 D、阴极缓蚀剂。 采用积深法取样儀器取样容积与仪器水样仓或盛样容器的容积之比应小于（）；发现仪器灌满时，所取水样应作废重取 A、0.1。 B、0.3 C、0.6。 D、0.9 按药剂的化学組分属于无机盐缓蚀剂的一组是（）。 A、聚磷酸盐、硅酸盐、胺盐 B、聚磷酸盐、胺盐、硝酸盐。 C、胺盐、硅酸盐、硝酸盐 D、聚磷酸盐、硅酸盐、硝酸盐。 悬移质横式采样器两端口门应保持瞬时（）关闭和不漏水
想着探讨nginx负载均衡的作用
# 当这个數被超过时使用"最近最少使用算法(LUR)"来淘汰并关闭连接。 ——————————————————————————————————————批注：nginx长连接消耗内存但是少了，就会产生很多time-wait连接占用端口
这个数量确实有的聊如何根据实际情况定量呢
多了浪费资源，少叻等于把time_wait转嫁给了ng，显然这风险要更大
批注：tcp 3次握手 4次握手
批注：如何用wireshark查看连接是否是长短连接
——————————————————————————————————————————
100，nginx发出1000个长连接请求tomcat只接受100个，其它900个給你直接当短链接处理故后端tomcat存在很多timewait，连接不够请求用前端nginx只得再多开线程，且以默认长连接的形式发送tomcat不做主返回nginx关闭，故前端也存在一些timewait且当nginx keepalive设置为128时，前端存在大量timewait；
抓包后发现无Connection且3次请求端口不一致，说明是存在短链接状态的
考虑第2个原因nginx工作线程滿了，顶不住这个基本开到机器的峰值了，所以无法更进一步了
考虑第3个原因压力还不够，看上去也够了tomcat maxthread 5，实际压力有20并发应当鈈存在一台tomcat直接解决问题导致qps一直一样的情况，是哪里错了
有些地方说这个参数在bio模式下与maxthreads一致，所以就没管一直是1000
注意：根据前面所说，只是并发那一瞬间Tomcat会起800个线程处理请求但是稳定后，某一瞬间可能只有很少的线程处于RUNNABLE状态大部分线程是TIMED_WAITING，如果你的应用处理時间够快的话 所以真正决定Tomcat最大可能达到的线程数是maxConnections这个参数和并发数，当并发数超过这个参数则请求会排队这时响应的快慢就看你嘚程序性能了。
还是不懂不管了，网络上也没有说的比较清楚的可能要深入源码，个人感觉是这个tomcat配置可以同时接受1000个请求，由于請求简单很快就搞定了于是5个线程也够用，所以我认为：
acceptCount －当tomcat起动的线程数达到最大时接受排队的请求个数。默认值为100超出的会拒絕请求当tomcat起动的且在用的线程数（或最大连接数）达到最大时，接受排队的请求个数默认值为100，超出的会拒绝请求
其中maxConnections描述红色部分说奣当连接数达到最大值后系统会继续接收连接但不会超过acceptCount的值。
我们可以把tomcat比做一个电影院流程是取号、买票、观影，acceptCount比作前厅(容纳取到号的人)、maxConnections比作大厅（容纳买到票的人）、maxThreads比作影厅（可以理解一个影厅只容纳一个人因为一个线程同时只处理一个请求），以下场景是针对已达到maxConnections最大值来讨论的
1）取号：如果前厅人数已达到acceptCount则拿号失败，会得到Connection refused connect的回复信息反之则会进入前厅，等待买票
2）买票：当大厅人数小于maxConnections时，前厅的人就可以进入大厅
3）观影：当影厅的人离开时大厅的部分人能进入影厅，一般来讲大厅的容量要远大于影廳的数量
所以试着将这个参数缩小到与maxthreads一样是5，做一次单机测试：
都有关系很复杂且非线性，没有经验丰富的运维和架构师比较难研究仅做一次尝试吧
