`
youxinrencwx
  • 浏览: 72401 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

慢连接&LazyParser

 
阅读更多

慢连接&LazyParser

Author:放翁(文初)

Mail:fangweng@taobao.com

Tblog:weibo.com/fangweng

这里要从实际的测试中给Web应用开发者一个比较直观的关于慢连接优化的建议。

测试目标:

1. 证明慢连接对于Java的应用容器的影响。

2. 不同前端反向代理服务器对于慢连接的处理差异。

3. 如何利用LazyParser的方式来优化慢连接请求(特别是大数据量的一些异常请求的处理)

测试部署环境描述:

Apache服务器(2.2.19版本)配置基本没变,增加了http proxy模块作为反向代理。

Nginx服务器(1.0.4版本)配置基本没变,增加了反向代理。

Jetty服务器(7.1.6版本)配置基本没变。JettyLazy解析缓存为8k

部署如下,外部请求可以通过三个入口访问应用真实逻辑。(apache,nginx,jetty

测试代码:

服务端:

简单描述一下逻辑:

1. 根据http消息头判断采用lazy还是普通方式解析。

2. 输出start test表示开始。

3. 获取key1,key2的内容,并记录消耗时间输出phase 1 use:xxx作为获取这两个参数的消耗。

4. 获取key4的内容,并记录消耗时间输出phase 2 use:xxx作为获取这个参数的消耗。

5. 获取key3的内容,并记录整个请求消耗的时间,输出end total use:xxx,作为整个处理消耗的时间。

客户端代码:

1. 配置不同入口访问应用。

2. 是否设置使用lazyhttp header来引导服务端处理。

3. 构建参数集合,参数顺序为(key1,key2,key3,key4)。其中key3作为一个大数据字段可变,用于多个场景测试。

测试结果及分析:

1. 设置key3大小为1000char,对比多个场景:

a. 不用lazy解析模式

(1) 通过nginx访问:

Nginx日志(第一位是消耗时间单位秒):0.002 115.193.162.12 - - [20/Jun/2011:10:50:44 -0400] "POST /cometpipe/slowtest?key1=1 HTTP/1.1" 200 19 "-" "Jakarta Commons-HttpClient/3.0.1" "-"

Jetty日志:

start test: not use lazy

phase 1 use :0

phase 2 use :1

end total use:1

(2) 通过 apache访问:

Apache日志:(第二位消耗时间单位微秒):0 3513 115.193.162.12 - - [20/Jun/2011:10:53:24 -0400] "POST /cometpipe/slowtest?key1=1 HTTP/1.1" 200 9

Jetty日志:

start test: not use lazy

phase 1 use :0

phase 2 use :0

end total use:0

(3) 直接访问jetty

Jetty日志:

start test: not use lazy

phase 1 use :1

phase 2 use :0

end total use:1

b. lazy解析模式

同样是上面三种模式,web容器的日志就不写出来了结果一样,下面主要是贴一下应用服务器的情况:

----------------------------------------------------jetty

start test : uselazy

Jun 20, 2011 10:57:24 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1019

phase 1 use :1

Jun 20, 2011 10:57:24 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: -1

phase 2 use :0

end total use:1

-----------------------------------------------------------nginx

start test : uselazy

Jun 20, 2011 10:58:37 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1019

phase 1 use :0

Jun 20, 2011 10:58:37 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: -1

phase 2 use :0

end total use:0

-----------------------------------------------------------apache

start test : uselazy

Jun 20, 2011 10:58:45 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1019

phase 1 use :0

Jun 20, 2011 10:58:45 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: -1

phase 2 use :1

end total use:1

上面的输出增加了一些,其实lazyparser在逐块解析字节流的时候每次装载数据的输出,lazyparser的缓冲区当前设置最大为8k,根据上面的情况可以看到不论哪一种方式,数据一次性都被装载,不存在后端处理的差异。

2. 设置key3大小为100000char,对比多个场景:

a. 不用lazy解析模式

(1) 通过nginx访问:

Nginx日志(第一位是消耗时间单位秒):1.528 115.193.162.12 - - [20/Jun/2011:11:05:34 -0400] "POST /cometpipe/slowtest?key1=1 HTTP/1.1" 200 19 "-" "Jakarta Commons-HttpClient/3.0.1" "-"(消耗时间大幅上升)

Jetty日志:

start test: not use lazy

phase 1 use :5

phase 2 use :0

end total use:6

(2) 通过 apache访问:

Apache日志:(第二位消耗时间单位微秒):1 1502243 115.193.162.12 - - [20/Jun/2011:11:07:10 -0400] "POST /cometpipe/slowtest?key1=1 HTTP/1.1" 200 9

Jetty日志:

start test: not use lazy

phase 1 use :609

phase 2 use :0

end total use:609

(3) 直接访问jetty

Jetty日志:

start test: not use lazy

phase 1 use :1463

phase 2 use :0

end total use:1463

从上面几个数据来看,首先不论哪个入口进去,总的时间处理都在1.5秒左右(我的网络状况还是比较烂),但nginx的数据堆积效果对jetty起到了明显的保护作用,使得jetty整个容器线程池生命周期较短,可以处理更多的请求,apache数据堆积不是全量堆积,因此对于jetty来说还需要自身的一些堆积处理(这点在后面的lazy模式下将会更加直观的看到过程)

b. lazy解析模式

(1) 通过nginx访问:

Nginx日志(第一位是消耗时间单位秒):1.513 115.193.162.12 - - [20/Jun/2011:11:13:22 -0400] "POST /cometpipe/slowtest?key1=1 HTTP/1.1" 200 19 "-" "Jakarta Commons-HttpClient/3.0.1" "-"(消耗时间大幅上升)

Jetty日志:

start test : uselazy

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 5911

phase 1 use :1

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 8192

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 8192

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 8192

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 8192

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 8192

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 8192

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 8192

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 8192

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 8192

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 8192

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 8192

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 3996

Jun 20, 2011 11:13:22 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: -1

phase 2 use :7

end total use:8

从上面的结果可以看到,nginx的数据堆积效果很好,jetty都是塞满lazyparser的缓存大小来处理的,所以Java IO次数少,整体消耗时间短。

(2) 通过 apache访问:

Apache日志:(第二位消耗时间单位微秒):1 1521576 115.193.162.12 - - [20/Jun/2011:11:16:37 -0400] "POST /cometpipe/slowtest?key1=1 HTTP/1.1" 200 9

Jetty日志:

start test : uselazy

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 5787

phase 1 use :1

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 8192

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 2405

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:13,count: 8096

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:280,count: 8192

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 448

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:6,count: 8192

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 448

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:13,count: 8192

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 448

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:10,count: 8192

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 448

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:265,count: 8192

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 448

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:7,count: 8192

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 448

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:13,count: 8192

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 448

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:7,count: 8192

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 448

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:6,count: 6419

Jun 20, 2011 11:16:38 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: -1

phase 2 use :627

end total use:628

可以看到第一阶段处理由于是lazy的模式,没有像普通请求处理那样消耗都在第一阶段,而是把消耗时间落在了真正要拿那些数据处理的第二阶段,同时可以看到apache有满cache和非满cache的数据后传,同时由于是变积累边传递,每次后传所消耗的时间都要远大于nginx,因此对于jetty的保护较弱。(所以如果你不是用mod_jk去直接反向代理到后段的应用容器(jboss,tomcat,jetty)都会使得应用服务器load比较高,线程生命周期长了,线程切换频繁)

(3) 直接访问jetty

Jetty日志:

start test : uselazy

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1217

phase 1 use :1

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:294,count: 1440

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:309,count: 1440

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:2,count: 1440

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:2,count: 1440

Jun 20, 2011 11:22:46 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:287,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:2,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:4,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:2,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:3,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:2,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:2,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:273,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:16,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:2,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:2,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:246,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:23,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:1,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 1440

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: 882

Jun 20, 2011 11:22:47 AM com.taobao.top.xbox.framework.http.LazyParser readBytes

SEVERE: timconsume:0,count: -1

phase 2 use :1532

end total use:1533

上面的输出大家会看到虽然我给了8klazy解析缓冲区,但是每次过来的数据都是1440,这个数字的含义大家可以去查一下TCP传输的数据包大小定义。可以看到,其实如果网络速度不佳,我们就会一个一个的得到数据包,Java IO次数及每次消耗的时间都会较长,同时这也是直接把Java应用服务器对外接收请求在高并发,慢请求的状况下,系统压力会远高于前端假设反向代理http服务器。

总结:

测试很简单,但说明了几个问题:

1. 互联网上的请求和内网测试环境完全是两码事情(如果你还打算支持mobile)。

2. Nginxapache作为反向代理,对于后端的web容器的处理是有一定帮助的,特别是nginx,作为数据堆积和海量连接的并发支持能够很好的充分利用后端应用服务器的线程资源。

3. 不论哪一种模式,总体请求时间都是差不多的,因此RT在后端资源不是瓶颈的时候,不会由于你架设了反向代理而得到优化,反而会有所增长(毕竟多了一层中转)

4. Lazy处理可以极大提高串行化分阶段处理的性能(特别是在没有数据堆积的情况下或者是apache这样的半数据堆积的情况下,在nginx模式下失效)。比如一个很大的请求,如果在第一阶段就被判断系统参数校验错误,那么后续的请求数据将直接拒绝(或者类似于有图片大小限制或者是图片个数限制的判断)。

5. 应用服务器(jetty,tomcat,jboss等等)不论使用nio或者bio模式,在慢连接的情况下都会有不小的性能消耗。

对于开放平台来说,每天处理几十亿的api call,和普通的web应用不同,每一次请求的时间就贯穿于容器对于数据流的载入,处理,一点优化都可以极大地提高整体的处理能力和资源使用效率,当前开放平台采用nginx+jetty,虽然可以保护到jetty对于高并发的慢连接支持,但是整体的响应时间及资源消耗状况都没有被充分利用到(虽然Lazy解析已经被装配上,apache+jboss时代比较有效果),因此后续考虑要做三种改进:1.nginx支持部分数据堆积模式。2.优化jettybio模式的nio3.替换掉jettynio模块(netty)。最终不是让前端采用部分堆积,就是直接暴露应用容器到外部,再加上lazyparser,来完成对于慢连接的优化。

分享到:
评论

相关推荐

    ProMesh-25584

    “LazyParser.NET”和“SharpTemplate.NET”可能是项目中使用的两个组件或子模块,前者可能是一个懒加载解析器,用于提高性能,后者可能是用于生成动态HTML模板的库。而“ProMesh.NET”可能是一个项目的主干代码文件...

    weloveinterns:中科院软件所智能软件中心实习生社区

    吴伟(lazyparser)是目前仓库的主要维护者。具体介绍可以从 看到。PLCT实验室 全称是程序语言与编译技术实验室。PLCT致力于成为编译技术领域的开源领导者,推进开源工具链及运行时系统等软件基础设施的技术革新,...

    基于django,html,css和js,配合nginx,thrift实现的可联机小游戏.zip(毕设&课设&实训&大作业&竞赛&项目)

    项目工程资源经过严格测试运行并且功能上ok,可复现复刻,拿到资料包后可实现复刻出一样的项目,本人系统开发经验充足(全栈),有任何使用问题欢迎随时与我联系,我会及时为您解惑,提供帮助 【资源内容】:包含源码、工程文件、说明等。资源质量优质,放心下载使用!可实现复现;设计报告可借鉴此项目;该资源内项目代码都经过测试运行,功能ok 【项目价值】:可用在相关项目设计中,皆可应用在项目、毕业设计、课程设计、期末/期中/大作业、工程实训、大创等学科竞赛比赛、初期项目立项、学习/练手等方面,可借鉴此优质项目实现复刻,设计报告也可借鉴此项目,也可基于此项目来扩展开发出更多功能 【提供帮助】:有任何使用上的问题欢迎随时与我联系,及时抽时间努力解答解惑,提供帮助 【附带帮助】:若还需要相关开发工具、学习资料等,我会提供帮助,提供资料,鼓励学习进步 质量优质,放心下载使用。下载后请首先打开说明文件(如有);项目工程可实现复现复刻,如果基础还行,也可在此程序基础上进行修改,以实现其它功能。供开源学习/技术交流/学习参考,勿用于商业用途,网络商品/电子资源资料具可复制性不支持退款。质量优质,放心下载使用。

    智慧化工园区信息化整体解决方案PPT(53页).pptx

    在当今化工行业转型升级的大潮中,智慧化工园区作为推动绿色、创新、高质量发展的关键力量,正逐步成为行业发展的新趋势。随着国家政策的不断引导和推动,智慧化工园区的建设已不仅仅是提升管理服务水平的手段,更是实现安全生产、环境保护和应急响应能力全面提升的重要途径。从提升重大危险源监测、隐患排查到完善风险分级管控机制,智慧化工园区利用信息化、智能化技术,构建了一个全方位、多层次的安全、环保、应急救援一体化管理平台。 智慧化工园区以安全、便捷、高效、节能、物联为核心理念,通过深度融合云计算、物联网、人脸识别、大数据分析、人工智能等先进技术,实现了园区生产、车辆、人员、环境、能源等关键环节的智能化管理。在基础网络方面,园区不仅实现了全千兆光纤接入,还覆盖了5G信号、NB-IoT信号和WiFi网络,为万物互联提供了坚实的基础。智慧安监作为园区的核心板块,通过企业安全云服务、安全文化宣传教育、舆情信息监管、风险分级管控、隐患排查治理以及重大危险源管理等功能,构建了从源头到末端的全过程安全监管体系。特别是企业一张表功能,实现了企业档案的数字化管理,为精准施策提供了有力支持。此外,智慧园区还通过物联网监测预警系统,利用智能终端设备对园区内的各类风险进行实时监测和预警,确保园区安全无虞。 在智慧节能与环保方面,园区通过智能仪表监测电、水、冷、气等能耗数据,实现能源管理的精细化和节能减排。智慧应急系统则融合了指挥调度、辅助决策等功能,能够在突发情况下迅速响应,有效处置。智慧环保系统则利用物联网技术和大数据分析,实现了环境质量的自动监测和预警,为环保部门提供了精准的执法依据。同时,智慧物流、智慧安防、智慧楼宇等系统的引入,进一步提升了园区的智能化水平和运行效率。这些系统的集成应用,不仅让园区的管理更加便捷高效,还极大地提升了园区的整体竞争力和可持续发展能力。对于正在筹备或优化智慧化工园区建设方案的读者来说,这份解决方案无疑提供了宝贵的参考和灵感,让智慧化工园区的建设之路变得更加清晰和有趣。

    教育资源汇总:助力课程与项目设计的全面资源指南

    内容概要:本文汇集了各类对课程设计或项目设计至关重要的资源及其获取途径。主要包括在线课程平台、开源项目平台、设计工具、项目管理工具、学习资源、社区与论坛、模板与素材、编程练习平台、硬件与开发板、云服务平台以及学术资源。每个部分详细介绍不同的资源网站或工具的功能和特点,并为读者指出了各个领域的最佳实践资源。 适合人群:高校师生及项目管理人员,尤其适用于需要制定高效课程或推进开发项目的人员。 使用场景及目标:该综述提供了从理论学习到实际操作所需的一系列实用资源链接和简介,帮助使用者更快地上手相关技术和工具,优化教学方式并提高开发效率。同时也可以作为个人成长路径上的指南,为自我进修提供方向指引。 其他说明:无论你是希望构建更完善的课堂授课计划还是希望增强个人项目执行力,本篇文档都能够为你提供有价值的参考资料和支持渠道列表,确保你能迅速找到最适合自己的工具和技术解决方案。

    基于灰狼算法优化SVR参数的多维输入单维输出回归预测模型及其精度提升表现,基于灰狼算法优化SVR参数的多维输入单维输出回归预测模型,精准预测并输出评估指标,基于灰狼算法优化SVR的c和g参数,实现多维

    基于灰狼算法优化SVR参数的多维输入单维输出回归预测模型及其精度提升表现,基于灰狼算法优化SVR参数的多维输入单维输出回归预测模型,精准预测并输出评估指标,基于灰狼算法优化SVR的c和g参数,实现多维输入单维输出的回归预测模型,提高模型的预测精度,具体的效果如下,同时模型可以输出模型的预测精度等评价指标,方便于判断模型的好坏, ,关键词:灰狼算法;SVR;c和g参数;多维输入单维输出;回归预测模型;预测精度;评价指标。,灰狼算法优化SVR模型:多维输入单维输出高精度预测

    齿轮生成器:轻松编辑参数,一键生成多种常用齿轮(约400MB,支持Creo格式),高精度齿轮生成编辑器:一键参数调整,轻松生成各类常用齿轮模型(Creo格式,约400MB),齿轮生成器 文件大小:约4

    齿轮生成器:轻松编辑参数,一键生成多种常用齿轮(约400MB,支持Creo格式),高精度齿轮生成编辑器:一键参数调整,轻松生成各类常用齿轮模型(Creo格式,约400MB),齿轮生成器 文件大小:约400MB 各种常用齿轮,点击重新生成编辑参数即可,是creo格式 ,齿轮生成器; 400MB文件大小; 常用齿轮; 重新生成编辑参数; creo格式。,《400MB齿轮生成器:Creo格式,一键编辑参数重新生成各种常用齿轮》

    本C++和Unity是智能手术室部分源码,获得湖南省创新创业大赛冠军,全国创新创业生物医药类优胜奖。.zip

    大创项目代码

    STM32F103C6T6控制NRF24L01

    STM32F103C6T6控制NRF24L01

    2000-2023年上市公司全要素生产率GMM法数据(含原始数据+计算代码+计算结果)

    2000-2023年上市公司全要素生产率GMM法数据(含原始数据+计算代码+计算结果) 1、时间:2000-2023年 2、来源:上市公司年报 3、指标:Year、证券代码、固定资产净额、资产总计、负债合计、员工人数 、成立日期 、上市日期 、所属省份、所属城市、企业性质、营业收入、税金及附加、营业利润、购买商品、接受劳务支付的现金、支付给职工以及为职工支付的现金、 购建固定资产、无形资产和其他长期资产支付的现金、固定资产折旧额、是否国有、上市年份、成立年份、是否发生ST或ST或PT、是否发生暂停上市、全要素生产率 4、范围:上市公司 5、计算方法:GMM法 6、参考文献: 鲁晓东,Z国工业企业全要素生产率估计:1999-2007

    代码备份代码备份代码备份代码备份叮嘱

    代码备份鹅鹅鹅鹅鹅鹅呃呃

    IEC 63093-14 2019.rar

    IEC 63093-14 2019.rar

    惠普HP Laser 102w 驱动

    基本信息 版本:以官方发布的 v1.0 版本为例。 大小:约 11.8M。 语言:简体中文。 适用系统:Windows 11、Windows 10、Windows 8、Windows 7。 功能特点 打印功能支持:能实现计算机向打印机发送打印任务,可设置多种打印参数。打印质量可在不同模式间选择,满足不同场景需求,如草稿模式适合快速预览,高质量模式用于重要文档输出。可选择多种纸张大小,包括 A4、Letter、A5、A6、信封等,还支持自定义纸张尺寸。能设置单面或双面打印,有效节约纸张。 状态监测反馈:实时反馈打印机的工作状态,如显示打印机是否处于就绪、忙碌、卡纸、缺纸等状态,让用户及时了解打印机情况,以便采取相应措施。可提示碳粉余量,方便用户及时更换碳粉,避免因碳粉不足影响打印工作。 网络连接管理:支持无线网络连接设置,用户可通过驱动程序将打印机轻松连接到 Wi-Fi 网络,实现多设备共享打印,摆脱线缆束缚,方便在不同位置的设备进行打印操作。

    mysql安装教程zip版本

    mysql安装教程zip版本安装详细教程

    基于S7-300 PLC的结晶器液位智能自动控制与多重组态界面管理解决方案,基于S7-300 PLC的结晶器液位智能自动控制系统:含梯形图程序、接线图与多种组态界面选择,基于S7-300 PLC结晶器

    基于S7-300 PLC的结晶器液位智能自动控制与多重组态界面管理解决方案,基于S7-300 PLC的结晶器液位智能自动控制系统:含梯形图程序、接线图与多种组态界面选择,基于S7-300 PLC结晶器液位自动控制系统 带解释的梯形图程序,接线图原理图图纸,io分配,组态画面 [红旗][hot]界面多种组态可供选择,详情请点头像查看 ,基于S7-300 PLC; 结晶器液位自动控制; 梯形图程序; 接线图原理图; IO分配; 组态画面,基于S7-300 PLC的结晶器液位自动控制系统:梯形图与组态画面详解

    LabVIEW网口TCP通讯:欧姆龙OMRON PLC一网打尽,源码开放,多类型数据批量读写,替代OPC插件,原创视频分享,LabVIEW网口TCP通讯:欧姆龙OMRON PLC一网打尽,源码开放,多

    LabVIEW网口TCP通讯:欧姆龙OMRON PLC一网打尽,源码开放,多类型数据批量读写,替代OPC插件,原创视频分享,LabVIEW网口TCP通讯:欧姆龙OMRON PLC一网打尽,源码开放,多类型数据批量读写,替代OPC插件,原创视频分享,LabVIEW网口TCP通讯欧姆龙OMRON PLC,FINSTCP NJ501 CJ2M,常用功能一网打尽。 1.源码开放。 2.支持 I16 I32 Float 批量读写。 3.支持字符串读写。 4.支持Bool批量读写。 5.支持Bool单点读写。 不安装插件,完胜OPC 等。 原创视频 创作不易,非诚勿扰。 谢谢大家。 ,LabVIEW;TCP通讯;OMRON PLC;FINSTCP;NJ501 CJ2M;源码开放;批量读写;字符串读写;Bool读写;不安装插件;完胜OPC。,LabVIEW PLC通讯工具:欧姆龙OMRON高效通信助手

    永磁同步电机凸极变交轴弱磁控制技术与仿真资料分享,附带基础模型及dq轴电流改进方案,永磁同步电机凸极变交轴弱磁控制技术与仿真研究:dq轴电流优化改进资料及基础模型赠送,永磁同步电机(凸极)-变交轴弱磁

    永磁同步电机凸极变交轴弱磁控制技术与仿真资料分享,附带基础模型及dq轴电流改进方案,永磁同步电机凸极变交轴弱磁控制技术与仿真研究:dq轴电流优化改进资料及基础模型赠送,永磁同步电机(凸极)_变交轴弱磁控制 资料包含仿真和相关文献资料,赠送仿真基础模型 dq轴电流跟踪效果不佳,可在此基础上做改进 ,核心关键词:永磁同步电机(凸极); 变交轴弱磁控制; 仿真; 文献资料; dq轴电流跟踪; 改进。,基于仿真资料的永磁同步电机凸极变交轴弱磁控制研究及模型优化

    基于Comsol仿真的涡流无损检测模型研究:探究频率、电导率、提离与线径对阻抗特性的影响,无损检测涡流检测模型的Comsol仿真分析:频率、电导率与阻抗关系研究,无损检测:涡流Comsol仿真 图一

    基于Comsol仿真的涡流无损检测模型研究:探究频率、电导率、提离与线径对阻抗特性的影响,无损检测涡流检测模型的Comsol仿真分析:频率、电导率与阻抗关系研究,无损检测:涡流Comsol仿真。 图一: 二维涡流检测模型 图二: 电导率140,频率80MHz下,磁通密度模 图三:0到100MHz下,频率和阻抗关系 图四:不同电导率和阻抗关系 图五:不同提离和阻抗关系 图六:不同线径和阻抗关系 一共是4个二维模型。 ,无损检测;涡流;Comsol仿真;二维涡流检测模型;电导率;频率;阻抗关系;提离;线径。,无损检测技术:涡流Comsol仿真与阻抗关系研究

    URP视差云,视差遮蔽映射(Parallax Occlusion Mapping, POM)实现

    URP视差云,视差遮蔽映射(Parallax Occlusion Mapping, POM)实现

    S7-1200 PLC在MCGS M7120型平面磨床电气控制系统中的改造实践,S7-1200 PLC与MCGS系统改造M7120平面磨床电气控制系统升级方案,S7-1200 MCGS M7120型平

    S7-1200 PLC在MCGS M7120型平面磨床电气控制系统中的改造实践,S7-1200 PLC与MCGS系统改造M7120平面磨床电气控制系统升级方案,S7-1200 MCGS M7120型平面磨床电气控制系统的PLC改造 ,S7-1200 PLC; MCGS 监控系统; M7120平面磨床; 电气控制系统改造; 自动化升级,S7-1200 PLC在M7120型平面磨床电气系统中的升级改造

Global site tag (gtag.js) - Google Analytics