若谷学院
互联网公司技术架构分享

Web服务请求异步化方案的测试总结

Author:放翁(文初)

Date: 2010/4/14

Email:fangweng@taobao.com

围脖: http://t.sina.com.cn/fangweng

这部分是结果,大家可以当看倒序的电影,后续会有前篇给出。

Web服务异步化

         包括两部分,数据传输层异步化(大家已经熟知的NIO),Http业务请求异步化(continuationsservlet3.0)。服务异步处理我将会有一个详细的说明文档(服务异步化的概念,服务异步化的几种标准实现,服务异步化容器的特点),后续给出。

Web服务异步化测试原因

         TOP应用特殊性:

1.自身服务能力由后端的服务能力决定。(对同步Web请求的转发)

2.后端服务部署等同性,但要求服务互不影响。

第一点导致TOP无法预估自身服务能力(不同后端服务处理速度下的TOP有不一样的支持能力),同时也无法应对在后端服务异常的情况下,整体的服务质量。

第二点导致TOP只有在物理上分隔不同服务提供者所对应的TOP集群(资源浪费,同时无法动态调整资源来满足服务变化情况)。

         因此需要对TOP实施web服务异步处理的测试。这里简单的说一下服务异步化的使用场景需要满足的几个特点:

1.       处理耗时大多消耗在于对后端或者外部服务资源的请求上。

2.       后端或者外部资源在更多的流量下不会成为瓶颈。

TOP来解释一下:TOP自身处理主要包括路由,安全,流控等,但是最耗时的是在请求后端各个淘宝团队的服务。其次当前后端服务能力尚未达到真实的处理高峰,因此很多请求被堵在TOP平台,特别是当某些服务异常的时候,另一些服务就会被拖累无法得到充分利用。(当然我们有流控,发现后端服务能力已经成为瓶颈的时候可以对单独服务作限制)。

长话短说,上测试结果……

环境说明

Linux 2.6.9-55.ELsmp

4 Core

4 G Memory

JDK 1.6.0_07

测试工具:loadRunner 9.5

测试涉及到了四种容器部署:后面都会用缩写在测试结果上注明

1.       Apache + modjk + Jboss(后面缩写为Jboss)

此模式Apache配置如下:

<IfModule mpm_worker_module>

ServerLimit          80

ThreadLimit          128

StartServers         10

MaxClients           10240

MinSpareThreads      64

MaxSpareThreads      800

ThreadsPerChild      128

MaxRequestsPerChild 10000

</IfModule>

   Jbossweb容器配置如下:

<Connector port=”8009″ address=”${jboss.bind.address}” connectionTimeout=”8000″ protocol=”AJP/1.3″ maxThreads=”500″ minSpareThreads=”40″ maxSpareThreads=”75″ maxPostSize=”512000″ acceptCount=”300″ bufferSize=”16384″ emptySessionPath=”false” enableLookups=”false” redirectPort=”8443″ URIEncoding=”utf-8″/>

Jbossweb部分以APR模式启动。

2.       Tomcat6APR

关键配置如下:

<Executor name=”topThreadPool” namePrefix=”top-exec-”

        maxThreads=”500″ minSpareThreads=”40″/>

    <Connector port=”7777″ protocol=”HTTP/1.1″

               executor=”topThreadPool” connectionTimeout=”20000″ acceptCount=”1000″

               redirectPort=”8444″ />

3.       Tomcat7 RC 4APR

关键配置如下:

    <Executor name=”topThreadPool” namePrefix=”top-exec-”

        maxThreads=”500″ minSpareThreads=”4″/>

    <Connector executor=”topThreadPool” port=”3333″ protocol=”HTTP/1.1″

               connectionTimeout=”20000″ acceptCount=”1000″

               redirectPort=”6443″ />

4.       Jetty7

关键配置如下:

<Set name=”ThreadPool”>

      <!– Default queued blocking threadpool –>

      <New class=”org.eclipse.jetty.util.thread.QueuedThreadPool”>

        <Set name=”minThreads”>10</Set>

        <Set name=”maxThreads”>500</Set>

    </Set>

    <Call name=”addConnector”>

      <Arg>

          <New class=”org.eclipse.jetty.server.nio.SelectChannelConnector”>

            <Set name=”host”><SystemProperty name=”jetty.host” /></Set>

            <Set name=”port”><SystemProperty name=”jetty.port” default=”6060″/></Set>

            <Set name=”maxIdleTime”>300000</Set>

            <Set name=”Acceptors”>2</Set>

            <Set name=”statsOn”>false</Set>

            <Set name=”confidentialPort”>8443</Set>

            <Set name=”lowResourcesConnections”>20000</Set>

            <Set name=”lowResourcesMaxIdleTime”>5000</Set>

          </New>

      </Arg>

    </Call>

附注:

Asyn表示异步模式,syn表示同步。Asyn中还分成resumecomplete两种方式,后续在介绍技术背景的时候详细描述。

         对于服务端的load不是每一个测试都做了记录,选取了最全面的1500并发用户做了测试。

         最大服务请求处理数是通过应用自身实现,具体代码可以参考后面的代码附件。

测试结果如下:

场景1500 并发用户场景下,后端服务一次请求消耗3秒钟

容器

模式

TPS

Average Response Time(s)

Average Throughput(byte/s)

最大请求处理数

Success rate

Jetty7

asyn(resume)

162.8

3.008

38430

500

100%

Tomcat6

syn

163.3

3.005

18453

500

100%

这个场景测试的目的是比较在线程池资源足够的时候,异步和同步的差别。(也就是TOP服务器所有的资源处于正常服务,前台请求没有因为前段连接被消耗完,导致服务质量降低)

         可以看到,在TPSResponse Time上两者基本上没有太大差别,TPS就等于500/3=167左右(3秒一个请求,因此用这种简单算式可以算出),响应时间也较为正常。当时我发现在每秒吞吐量上有些差别,后来单个测试case跑了一下,发现是返回的http header比较大,应该是在做异步化时重入等作的一些标识(后面其他容器的异步化也是一样)。

         最大处理请求数都在服务端后台看到是500,等同于最大的并发用户数。

场景21000 并发用户场景下,后端服务一次请求消耗3秒钟

容器

模式

TPS

Average Response Time(s)

Average Throughput(byte/s)

最大请求处理数

Success rate

Jetty7

asyn(resume)

317.06

3.036

74826

1000

100%

Tomcat6

syn

163.323

5.904

18455

500

100%

         场景2就在资源不足的情况下,比较异步服务请求与同步请求处理能力。(例如由于后端某些服务比较慢,导致前段的服务器能够承载的请求数目超过了线程数)

         这个场景的结果可以看到TPS在异步模式下与并发用户数呈现同步增长,就好比配置了1000个线程作为线程池一样,同样在后端打出的最大请求数上也证明了这一点,因此前段线程池的服务能力在异步的情况下充分复用(当然这里使用的异步服务处理使用的是NIO而不是BIOConnector)。同样在吞吐量上依然是增加的,由于异步附加的内容。

场景31500 并发用户场景下,后端服务一次请求消耗3秒钟

容器

模式

TPS

Average Response Time(s)

Average Throughput(byte/s)

Server Load

Success rate

Jboss

syn

75.546

5.347

21002

0.115

68%

Jetty7

Syn

163.156

8.788

19252

0.129

100%

Jetty7

Asyn(complete)

432.153

3.312

76491

2.649

100%

Jetty7

Asyn(resume)

423.638

3.375

99979

2.826

100%

Tomcat6

Syn

163.836

8.75

18513

0.258

100%

Tomcat7

ASyn

423.501

3.328

54632

1.064

99.3%

场景三比对了现有TOP的部署模式(Apache + modjk + Jboss)和Jetty7的同步模式,两种异步模式,Tomcat同步模式,Tomcatservlet3.0异步模式的处理情况。根据测试可以得到的信息如下:

1.              现有部署方式在后端服务处理耗时较大的情况下,处理能力不如Jetty7Tomcat6,同时出错率很高。

2.              Jetty7的同步处理测试结果和Tomcat6的同步处理测试结果很类似,但是load方面jetty7更好。

3.              异步处理方面Jetty7的两种方式基本上差别不大(后续还需要深入源码看看对于数据缓存资源复用的状况),Tomcat7的异步处理成功率有些问题(错误多半是在获取response回写的时候,response已经被提前释放,看来Tomcat7还是需要一些时间来考验),load上来说tomcat结果比较好。

4.              异步请求在提高处理能力的情况下,对于资源消耗也较大(线程切换较为频繁),不过还是在承受范围。

三个场景组合比较:

容器

并发用户

模式

TPS

Average Response Time(s)

Average Throughput(byte/s)

Success rate

Jetty7

500

asyn(resume)

162.8

3.008

38430

100%

Jetty7

1000

asyn(resume)

317.06

3.036

74826

100%

Jetty7

1500

asyn(resume)

423.638

3.375

99979

100%

Tomcat6

500

syn

163.3

3.005

18453

100%

Tomcat6

1000

syn

163.323

5.904

18455

100%

Tomcat6

1500

Syn

163.836

8.75

18513

100%

最后将三个场景合并起来做一个简单的比较,得到信息如下:

1.       随着并发用户的增加,本身异步处理也会有衰减,同时对于性能消耗(线程切换)也会不断增长。

2.       异步化在消息头上会增加一些数据,会增加回写的带宽消耗(不过量不大),一个请求增加了100byte左右的消息数据。

测试总结:

1.       Web请求异步化在TOP很合适。

重复两个条件:

a.       处理耗时大多消耗在于对后端或者外部服务资源的请求上。

b.       后端或者外部资源在更多的流量下不会成为瓶颈。

2.       Web请求异步化在Jetty67上已经经历了2年多的成长(Google App Engine , Yahoo Hadoop),稳定性和效率较好。(同时很多优化可以通过扩展自行定制,jetty的可扩展性很好Tomcat7servlet3上处于刚发布阶段,还有待继续完善。(Servlet3的另一种模式尚未执行成功,直接导致jvm退出)

后续需要继续跟进的:

1.       对于大数据量请求的容器间性能对比。(图片上传或者大数据量的Post请求)

2.       容器安全性。(是否容易被攻击)

3.       代码迁移成本。

后续篇涉及:服务异步化的概念,服务异步化的几种标准实现,服务异步化容器的特点和实现,现有容器可优化的点。

 打个广告:http://blog.open.taobao.com/archives/1417 TOP需要人才加入

原文出自:https://blog.csdn.net/cenwenchu79/article/list/3

好烂呀没啥价值凑合看看还不错很精彩 (还没有人评分)
Loading...
本站文章来自互联网一线技术博客,若有侵权,请联系我们:若谷技术学院 » Web服务请求异步化方案的测试总结
关注若谷技术,获得个性化即时架构文章推送

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

全球互联网技术架构,前沿架构参考

联系我们博客/网站内容提交