`
xiaoY
  • 浏览: 8488 次
  • 性别: Icon_minigender_1
  • 来自: 上海
文章分类
社区版块
存档分类
最新评论

SEDA性能优化的分析和模拟

阅读更多

 

 

在学习Mule的过程中,发现MULE对于服务调用的性能做了不少优化工作,其中最显著的就是实现SEDA模型。

Staged Event Driven Architecture (SEDA) 是加州大学伯克利分校研究的一套优秀的高性能互联网服务器架构模型。其设计目标是:支持大规模并发处理、简化系统开发、支持处理监测、支持系统资源管理。它的核心思想是把一个请求处理过程分成几个Stage,不同资源消耗的Stage使用不同数量的线程来处理,Stage间使用事件驱动的异步通信模式。

可以参考

http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf

http://larryzhu.bokee.com/6779982.html

http://www.ibm.com/developerworks/cn/java/j-jtp0730/

这几篇文章对SEDA和线程池相关知识有着详细的介绍,这里就不复述了。

了解了SEDA后可以看出,经过它的改造,一个请求的处理过程被分为了很多个stage,并且使用了事件驱动的异步通信。接收到请求的最初始的线程所做的事情仅仅是将请求转换为一个event然后放入一个Stage的事件队列中。每个Stage都有自己的线程池,来处理事件队列中的事件。与另一个 stage的通信也是通过在eventQueue中添加event的方式。

 

 

为什么要做此改造?

 

可以分析下面这个例子

前提假设:在一个单核系统中存在A、B、C、D四个组件,他们向外暴露服务。四个组件中A C D是进行普通业务处理,而B会涉及到调用WebService或大数据量查询等导致长阻塞的处理。现有两个请求R1和R2,R1需要的业务处理会调用A- C-D组件,R2的业务处理会调用C-B组件。假设R1请求过程中的CPU使用时间ST(Service Time)是2ms, 而几个简单的数据库访问导致的阻塞时间WT(Wait Time)是10ms。 R2请求过程中CPU使用时间ST是3ms,而调用WebService和大数据量查询导致的阻塞时间WT是150ms。

在传统线程池的方案中,对于具有N个处理器的系统,需要设置大约 N*(1+WT/ST) 个线程来保持处理器得到充分利用。理解起来很简单,就是需要在WT的阻塞时间内提供足够的线程来保持CPU一直进行ST的处理,达到最大的CPU利用率。

通过计算可以得到,R1需要的线程池大小是6,R2需要的线程池大小是51。若仅仅在接收请求时使用传统的线程池方案,R1、R2两种请求同时高并发时,线程池对他们一视同仁,假设线程池的大小是80,而并发数是1000,按照公平的假设,80大小的线程池平均的被分配给R1和R2两种请求,各拿 40。这样导致的结果就是,R1只需要6个线程却被分配了40个线程,浪费了资源,增加了额外的调度工作;R2需要51个线程却只分配了40个,会导致 40个线程全部阻塞时没有足够新线程处理其他的并发请求,CPU没有充分利用,请求处理速度下降,系统吞吐量下降。

这里的数字全部是假设,仅供分析。事实情况下的并发数和线程池都会大很多,但上面分析得出的结论同样适用。

不难看出解决上面问题的方法就是能够为不同的请求分配不同的线程数量。但是一个请求会交给多个组件进行处理,组件的调用关系和请求的数量种类都会不断变化,所以不可能静态的为每个请求配置线程池大小。但是组件却可以,系统中ABCD四个组件是可以确定的,他们的WT和ST也是可估的,可以为每个组件的服务设计线程池大小。若要为每个组件设计线程池,组件间的调用也需要由同一线程内的同步调用,改造为事件驱动的异步通信方式。

于是,SEDA的方案被设计出来了。上面的组件对应的就是SEDA中的一个个阶段stage。分阶段的事件驱动架构的原理也展现在眼前。

实际演练

在分析了SEDA的原理和作用后,我模拟了他最简单的功能,实现了一个简单的SEDA模型,并进行了一些实验和比较,亲身体验到了他对性能的优化。下面是实验过程:

首先,实现一个简单的SEDA模型以及测试器,见附件的 SedaTester.java和seda.properties,分别是模拟代码和相关参数的配置文件。为了方便,我将功能代码写在了同一个类中。

代码中有详细的注释,这里就不解释了,简单介绍一下它的结构和配置参数:

模拟器实现了两种并发处理,包括传统的线程池处理,对应图中NormalComponent部分,以及SEDA方案,对应图中SedaComponent部分。

此模拟器主要是为了测试性能上的优化,为了简化,没有设计组件之间事件驱动的异步通信,一个请求的处理过程只涉及到一个组件。不过它已经能体现出SEDA的优势——为不同的请求分配不同大小的线程池。

配置文件中,为两个请求对应的两个组件分别配置了ST和WT值,以及两个请求的并发数量,如果是使用SEDA,还要分别配置两个组件线程池的大小。 useSEDA这个boolean属性表示是否使用SEDA,不使用SEDA将使用普通的线程池进行处理,线程池的大小是两个SEDA组件线程池大小的和(sedaPoolSize1+sedaPoolSize2),这样能保证两种方案的线程总数一致。

下面是我个人的实验结果

ST1 WT1 ST2 WT2 sedaPoolSize1 sedaPoolSize2 count1 count2 结果
0.1 30 0.1 100 200 300 5000 5000 Seda:1875ms

 

Normal:1690ms

0.1 30 0.1 100 100 400 5000 5000 Seda:1594ms

 

Normal:1656ms

0.1 30 0.1 100 50 450 5000 5000 Seda:3172ms

 

Normal:1656ms

0.1 3 0.1 300 200 300 5000 5000 Seda:5343ms

 

Normal:3453ms

0.1 3 0.1 300 10 490 5000 5000 Seda:3375ms

 

Normal:3410ms

0.1 3 0.1 300 100 900 5000 5000 Seda: 1968ms

 

Normal:3482ms

0.1 3 0.1 300 38 962 5000 5000 Seda: 1890ms

 

Normal:3422ms

0.1 3 0.1 300 38 962 50000 50000 Seda: 16107ms

 

Normal:17085ms

0.01 3 0.01 300 38 962 50000 50000 Seda: 15450ms

 

Normal:23430ms

0.1 3 0.1 300 138 2962 30000 30000 Seda: 3895ms

 

Normal: 65664 ms

0.1 3 0.1 300 138 2962 300000 300000 Seda: 31574ms

 

Normal:76412ms

0.1 3 0.1 300 138 2962 300000 300000 Seda: 31761ms

 

Normal:94426ms

0.1 3 0.1 300 138 2962 300000 300000 Seda: 31561ms

 

Normal:???? ms

实验数据看似零乱,其实比较后不难发现,是按照两组件的WT比值、线程池大小比值的规律进行实验的。

结果分析:

1 在前几组数据中,SEDA的优势没有体现出来,原因可能是两个组件的WT相差不是很大,线程池和并发数量不大,不能体现出动态分配线程池的优化效果,相反会因为SEDA内部的线程管理和调度花费较多的时间,出现比传统线程池低效的结果。

2 在逐渐加大WT比值后,本来希望SEDA能体现优势,但是红色的数据显示了相反的情况,调整了线程池大小后发现红色数据中SEDA低效的原因是:两个组件线程池大小的比例不够大,只有200/300,而WT的比值是3/300,线程池大小的比值应该和WT的比值在某种程度成正比。当WT比值加大后,线程池的比值也需要加大调整。

3 逐渐好转后,到了橘黄色的数据已经比较明显的体现出了SEDA的优化,一方面是WT比值加大,两个线程池大小也调整到了较合适的比值,并且总的线程数量增大到1000,是原来的两倍,SEDA优化的效果开始体现。

4到了蓝色的数据,减少ST到0.01,并发增加到10万,SEDA比Normal缩短了8秒左右。

5 再下面的实验中,增加并发到了60万,线程池总数增加到3100,适当调整线程池比例后,SEDA已经能够缩短几十秒的时间。

特别是绿色标识的数据,优化的效果已经有点让我怀疑是不是我代码出了问题,是不是模拟器不能正确的测试出性能。这个也有待进一步确认。

6 最后一行数据之所以用四个问号来表示Normal的时间,是因为某几次实验过程中消耗的时间已经涨到200多秒而且还在不断继续上涨,不符合正常的预估。不知道是不是因为大并发和较大容量的时候,传统的线程池容易出现性能的异常。

 

总结一下,当不同请求的WT比值越悬殊、线程池大小越接近机器性能所允许的最大值、并发数量越满负荷、两个线程池大小的比值越合适时,就越能体现SEDA的优化效果。同时,必须根据某种算法,将两个组件的线程池大小调整到合适的比值(和WT的比值成正比),才能发挥SEDA的作用。否则,不合适的线程数目分配将严重折损SEDA的优化效果甚至产生反效果。

 

  • 大小: 15.9 KB
  • 大小: 14.6 KB
  • 大小: 38 KB
分享到:
评论
2 楼 xiaoY 2009-07-24  
图片显示不出来是因为图片上传在我公司的内网
1 楼 xuyao 2009-07-24  
别抄袭别人的行吗,图片都显示不出来

相关推荐

    如何利用SEDA提高系统的性能和稳定性 开发可掌控高并发服经验分享:非阻塞+异步化+队列 共19页.pptx

    SEDA(Staged Event Driven Architecture,分阶段事件驱动架构)是一种有效的方法,它通过非阻塞、异步化和队列的策略来提高系统的性能和稳定性。本篇将深入探讨SEDA的原理和应用,以及如何结合实际经验来优化服务端...

    seda eclipse工程可运行版

    - **控制接口(Control Interface)**:允许系统管理员或应用程序调整SEDA架构的参数,如队列长度、处理器数量等,以适应不同的工作负载和性能需求。 **2. SEDA的优势:** - **并行处理**:通过事件队列隔离,SEDA...

    seda架构

    **SEDA架构详解** SEDA(Staged Event-Driven Architecture),即分阶段事件驱动架构,是一种面向服务的...在实际开发中,结合源码学习和工具辅助,可以更好地理解和实现SEDA架构,从而提高系统的整体性能和稳定性。

    基于SEDA的异步框架设计与实现

    在实际开发中,可能会用到一些工具来辅助构建和调试基于SEDA的应用,如监控工具(如JMX)来监控各个阶段的性能,或调试工具(如VisualVM)来定位性能瓶颈。 在《基于SEDA的异步框架设计与实现》文档中,作者可能...

    SEDA的企业服务总线的设计与实现

    阶段事件驱动架构(Staged Event-Driven Architecture, SEDA)是由加州大学伯克利分校提出的一种高性能互联网服务器架构模型。SEDA的目标是支持大规模并发处理、简化系统开发、支持处理监测和支持系统资源管理。SEDA...

    SEDA-sosp.pdf

    ### SEDA:一种面向大规模并发...实验结果表明,在面对巨大负载波动的情况下,SEDA应用相比于传统设计展现出更优的性能和更强的鲁棒性。未来,SEDA架构有望成为构建高效、可靠的大规模并发互联网服务的关键技术之一。

    基于SEDA的企业服务总线的设计与实现

    本文主要探讨了如何通过采用阶段事件驱动架构(SEDA)来优化企业服务总线(ESB)的性能,特别是在高并发请求场景下。随着面向服务架构(SOA)在企业级软件开发中的广泛应用,ESB作为SOA的核心组件,对于实现跨系统的...

    seda-release

    综上所述,SEDA架构提供了一种有效处理高并发问题的方法,通过分解复杂任务、利用非阻塞I/O和事件队列,实现了系统的可扩展性和性能优化。对于需要处理大规模并发请求的现代互联网服务来说,理解和应用SEDA框架是...

    基于SEDA架构的网格服务容器设计与实现.pdf

    SEDA架构的设计理念对于当前和未来的网格计算平台有着深远的影响,它通过将复杂的系统分解为多个简单的阶段,每个阶段可以独立地进行扩展和优化,从而有效地提升了整个系统的性能和可伸缩性。这种分阶段的设计方法...

    SEDA-兼谈服务器体系结构设计.doc

    总结来说,SEDA是一种为了解决高并发环境下服务器性能瓶颈问题而提出的先进体系结构,它通过将处理流程划分为多个阶段并采用事件驱动的线程模型,实现了资源的高效利用和对OVERLOAD的有效控制。这种设计方法在现代...

    2017-11-07 Seda 安装配置笔记1

    【标题】:“2017-11-07 Seda 安装配置笔记1”描述了一次在Ubuntu 14.04环境下对Seda软件的安装与配置过程,涉及了VMware虚拟机、依赖软件的安装、LLVM与Clang的编译以及Seda的编译和配置。 【描述】:首先,安装...

    seda overload management.pdf

    通过以上内容,我们可以理解“seda过载保护”不仅仅是一个技术问题,而是一个涉及到系统设计、资源管理和互联网服务鲁棒性的整体问题。在未来的互联网服务和分布式系统设计中,如何合理地引入和管理过载保护机制将...

    Java工程师技能图谱.pdf

    同时,还需要熟练掌握JVM的线程堆栈等数据分析、内存dump和内存分析工具,以及JVM问题排查分析的常用手段和性能调优的最佳实践经验。 2. 多线程和并发编程:需要掌握线程、锁、synchronized、volatile、final、...

    Wake:Wake是一个事件驱动的框架,基于SEDA,Click,Akka和Rx的思想

    我们实现了Wake以支持高性能,可扩展的分析处理系统(“大数据”应用程序),并已使用它来实现控制平面逻辑(要求高扇出和低延迟)和数据平面(要求高通量处理)以及)。背景唤醒应用程序由运行在阶段内部的异步...

    ehensin-seda:舞台事件驱动架构

    此外,ehensin-seda可能还提供了监控和日志功能,帮助开发者跟踪和优化系统性能。 **学习与实践** 要深入了解ehensin-seda,可以访问其官方网站获取最新的文档、示例代码和社区支持。通过实践项目,可以更直观地...

    AIDC分布式高性能交换机制研究.pdf

    本文研究了AIDC分布式高性能交换机制的设计和实现,旨在满足空中交通服务设备间数据通信的需求。AIDC协议是一种统一的协议,旨在让不同自动化生产厂家的系统能够共享数据。然而,传统的报文交换方式存在时延和稳定性...

    SEDA - An Architecture for Well-Conditioned, Scalable Internet Services - Deck (seda-sosp01-talk)-计算机科学

    SEDA: An Architecture for Scalable,Well-Conditioned Internet ServicesMatt Welsh, David Culler, and Eric BrewerUC Berkeley Computer Science Division mdw@cs.berkeley.eduhttp://www.cs.berkeley.edu/~mdw/...

    稀疏指数判别分析

    稀疏指数判别分析(Sparse Exponential Discriminant Analysis,SEDA)是一种用于解决监督分类和降维问题的算法。它基于指数判别分析(Exponential Discriminant Analysis,EDA)进行发展,后者利用扩散映射解决了...

Global site tag (gtag.js) - Google Analytics