（计算机科学与技术专业论文）基金报表系统性能的分析与提高.pdf

摘要 基金报表系统是一个基于w 曲的j 2 e e 系统。该系统可以让基于浏览器的客 户端自定义报表，将w e b 请求发送至中问件，然后中i 日j 件对后台数据库进行处 理，最终生成用户所需要的报表这样的企业级系统对数据吞吐量和事务处理都 有严格的要求，影响性能的因素非常复杂，性能也成为重要的衡量指标。 本文以基金报表系统的性能改善为研究对象，从系统层面入手，研究构成 j 2 e e 系统的基本组件之问的关系及运作原理，从而揭示出改善系统性能的关键因 素。然后分别深入分析了应用服务器、设计模式、虚拟机和硬件平台方面影响性 能的因素，并且研究利用a p a c h e 公司的丌源项目j m e l 玎进行性能调优的方法， 以证明理论在实际中的应用。 本文通过理论研究和实践，总结出一套j 2 e e 系统性能优化的方法，在基会 报表系统中应用具有明显的效果，对系统的性能有一定的提高，同时，文章还探 索了其它的j 2 e e 组件，例如j m s 在系统中使用的可行性，提出进一步改善基金 报表系统性能的方法。 关键词j a m 虚拟机，性能，j m 神基金报表系统 浙江大学硕上学位论文 a b s t i a c t f m l dr e p o r t i n gs y 咖mi saw 如b a 捌s 拇锄u s i n gj 2 e e 盯c i l i t e c n 卫旧t 1 i es y s t e ml e i u s 盯d e 矗n ec i l s t o m i z e de x h i b i t s ，鲫l dw e b q u 鼯tt om i d d l 争w m ，蛐d 也t 1 1 e m i d d l e w a mw i l ld e a lw i mt l l eb a c k 锄dd a c a b a 锄da tl a s t 聪l e r a t em er e p o r t sf o r u s e 鹅t ov i e 、t t l i sb n do f t 删s es y s t 锄h o l d sas 雠n 蹦l t 托q u i 砸n 蹦tf b fd a t a n l ：r o u 曲p u t 锄d 仃a n s a c t i o h o w e v e 瓦m ef a c t o r st l l a ti i l 玎u c et l l ep a 暖脚a n c ca r 它 v e r yc o m p l 旺 i nt h i sp 印im a i l i l y 锄a l y z e 吐惦p e 雨彻a n c eo f f i l l l dr e p o n i n gs y s t 锄f i r s to f a l l ， i 柚a l y z e d l es y s t 锄i e v dp a 3 p e c t i v e ih a dal o o ka th o wd i 丘的l tp a r to ft l l e s y s t 黜w o r kt o g e m c rt os p o tw l l i c hp a r ti s t l l eb o t t i 舶e c ko fl h es y s t 锄；t l l 瑚，r e v e a l t h ek c ym e 勰u r 锶t 0e i l l l 锄c ep c r f o 姗柚c e n c x t ，m ea p p l i c a t i s e r v d 铝i 朗p a t t 锄， v i 删m a c h i n e 锄dh a r d w a r ep l a t f o 瑚a r ei n v e s t i g a t e d s p e c t i v c l yt o 吼1 t l a n c e p 曲肌a n c e i ) l m n gm ep r o c e s s ，it a k ea d v 柚t a g eo fj m 既e f ap e r f o m 髓m o n i t o r p 0 0 lb y a p a c h e 。t 0t e s tt l 坞p e r f o f i n 柚c e t h r o u 曲m r e t i c a lr 髂e 鲫c h 锄dp r a c l i c c t h ep a p 盯c o n c l u d 髂as e to f m e a 地t os 仃四s m ep 廿辆柚c eo f j 2 e es y s t a n s t h e s cm e a 璐a r ea p p l i e di nf 蛐dr q ) o f t i n gs y s t 锄 a n d 溅e v e do u t s t a n d i n ge 伍b c t m e a r l w h i l e ia l s oe ) 【p l o r e m eo t l l e rj 2 e e c o m p o n e n t s ，f b re ，【锄p l e 山ej m s ip r o b ei i l t ot l l ep o s s i b 订i t yo f 也ei n v o l v e m 锄to f j m si i in l i sg y s t 啪，a n dp r o p o 辩t l l ef i l | 曲e rm s i | r 髂t oa l l l 觚c ct l i ep e r f b 肋锄c co f f m l dr l 节o n i i l gs y s t 锄 k e y w o r d s j a 、av i r t u a lm a c l 洳e p e r f b 姗锄鸭j m e t f 岫dr e p o r t i n gs y s t 锄 浙江大学硕上学位论文 晤目录 图2 1f 系统的主页 图目录 图2 2f 系统的架构示意图4 图2 3f 系统架构的基础组织示意图。5 图2 - 4f 系统的全局页面流程5 图2 5f 系统中含四个容器的e x l l i b i t 6 图2 6 参数设置的w 曲页面7 图2 7f 系统报表 图2 - 8p 系统报表 图3 1 性能优化需要考虑的三个层面： 1 系统层面，应用层面以及硬件层面 1 l 图3 2 吞吐量曲线图，它表明了系统吞吐量。1 3 图3 3 基于服务器的两个容器，分别是w 曲和e j b 容器1 6 图3 4 使用会话门面之前和之后的序列图。1 8 图3 - 5s u n 的j v m 的年轻代和旧代2 3 图4 1a d a c h c 公司的j m c t 贯。2 7 图4 - 2m i c r o f i 提供的性能监控工具2 8 i 璺l4 3j r o c l ( i t 控制台2 9 图5 1f 系统的拓扑结构图3 l 图5 2f 系统中测得的吞吐量曲线图3 2 图5 3f 系统中对表f rr u ns t 棚i s 的对应表示3 5 图5 _ 4 在f 系统中的修改功能。3 7 图5 5 在f - 系统中的修改功能，在页面右部选择了一个强h i b i t 之后3 7 图5 6 在f 系统中的修改功能3 8 图5 7 在f 系统中的修改功能，在点击了某一个c t a i n 茁之后3 9 图5 8 使用会话f a c a d e 之前的方法调用层次4 1 图5 - 9 使用了会话f a c a d e 后，新的方法调用层次4 1 图5 1 0f 系统中的d d e 鼬t c 4 2 图5 1 1w 曲s p h e 所提供的b 锄高速缓存的设置4 5 图5 1 2 本功能的流程图4 6 图5 1 3j m e 【e r 中的线程组设置4 7 图5 1 4j m c t 盯中的h t r p 请求设置4 8 图5 1 5j m c t 口中的请求，r e m e v c e ) 【l l i b i t s d o 的设置4 9 图5 1 6 a c t i v a t c da t 为o n c e 的测试结果5 0 图5 1 7a c t i v a t c da t 为n 认n s a c t i o n 的测试结果5 l 图5 。1 8 警锈氏s 管理控制台：线程池大小5 2 图5 1 9w a s 管理控制台：b 锄池大小5 3 图5 - 2 0w a s 管理控制台：j 、1 参数5 4 图5 2 1w a s 管理控制台：堆参数的默认状态5 5 m 浙江大学硕i ：学位论文阁日录 图5 2 2w a s 管理控制台：重新设置的堆参数。5 5 图5 - 2 3 、) v = a s 管理控制台：j r r 设置。5 6 图5 2 4j m e 时测试结果：使能j 1 1 r 5 6 图5 2 5j m 积测试结果：禁用j r r 图6 1f 系统中的运行报表功能5 9 浙江大学硕士学位论文 囊l | 录 表目录 表3 1 瓜o c 始中对象分配的参数 表5 一l 数据库表f r e ) 【h i b i t s 表5 2 数据库表f rr u ns 1 1 a 矾7 s 。3 4 表5 - 3w 曲印h e r e 所提供的e j b 缓存参数4 5 表5 - 4 初始堆大小参数5 4 表5 5 堆最大容量参数。5 4 表5 - 6 堆的年轻代参数r 5 5 表5 7j d k 版本与推出时间 v 浙江大学硕上学位论文第l 章p 系统概述 第1 章p 一系统概述 1 1p - 系统背景 本基金报表系统源于一个叫做p _ 系统的遗留系统。p 系统是在8 0 年代开发 的项目它主要的功能是评价过去在基金上的操作，并进一步产生相关的报表让 投资者和投资经理们更清楚地了解他们在资产管理和投资决策上的表现。 卜系统最初是由一家外国银行在8 0 年代早期开发的，然后系统被卖给了我 方。在p _ 系统运行了2 0 年之后，它变得不堪重负而且也在很多方面无法满足用 户的需求。除此以外，从技术的角度来看，p 一系统中所采用的技术过于陈旧而且 它的架构和设计模式反映的也是那个年代的技术水平。所有这些都使重建这个系 统成为必须，而这正是我所在工作小组的工作内容。 1 2p - 系统的结构 p - 系统基于原始数据( 如，资产分配，价格等等) 计算得到一些性能方面的 数据( 收益，风险，风险收益比等等) 并为用户产生报表。这些原始数据一般从 几个应用程序中收集。 系统共有三个主要的入口，其中一个是供普通用户使用的( 简称a 系统) 。 一个是供独立咨询合作组织用户使用的( 简称b 系统) ，最后一个是一个菜单系 统是供商业分析员和系统管理者使用( 简称c 系统) 。第三个子系统属于p - 系统 的一部分，而前二个则不属于。 菜单系统( c 系统) 提供的功能是：对投资者( s p o n s o r ) ，账户( a c c o u n t ) ， 投资类别( c a t e g o r i e s ) ，证券，证券特征，投资时间段( p e r i o d ) 等各种基本信 息进行维护。 b 系统是被设计用来向独立咨询合作组织的成员提供在线或者是纸张形式的 关于基金表现和基金经理的表现的度量和分析报告的。该系统提供了一个用户友 好的操作环境，并使输入b 系统的数据存入本地的基于个人电脑的数据库。然后 本地数据可以被上传到p _ 系统的数据库中。 输入的数据可以通过手工方式上传到p 一系统，或者也可以通过f t p 方式定时 地自动上传。然后，数据就在p 一系统中被计算。在一年中的每个季度的季度末， p - 系统就会产生报表，以供用户选择下载。 浙江大学硕士学位论文第l 章p - 系统概述 1 3p 一系统的报表功能 p _ 系统中产生报表的过程如下： 一个预先设定的进程在队列中沉睡，它会在每天午夜运行来检查是否存在数 据库中的数据变动。如果用户在当天的白天曾经上传过某些最新的数据或者某些 数据因其他各种原因被更新了，这个进程就会马上发现这些数据库中的变化并准 备特定文件( s a s 程序的驱动文件) 当用户通过b 系统发送产生一个新报表的请求指令，负责报表功能的部分就 会使用前一晚准备好的s a s 驱动文件，然后调用s a sb i ( b u s i n e s si n t e l l i g e n c e ) 来产生p d f 格式的报表并把报表发送回给用户。 p - 系统的报表功能的未来目标是能够放弃a l p h a s 系统并且把这些原本在 a 1 p h a 上运行的模块转移到a i x 操作系统上。 在p - 系统中，s a s 所扮演得角色虽重要但不够灵活。它附属于b 系统；用户 没有其他选择只能通过复杂的b 系统来产生报表所以说，对一个灵活的独立的 报表系统的需求变得十分迫切。 2 浙江大学硕七学位论文 第2 章基金报表系统 第2 章基金报表系统( f u n dr e p o r t i n gs y s t e m ) 2 1 概述 基金报表系统( f u n dr e p o r t i n gs y s t e m ) ，简称f 系统( 下文同) ，是以上一 章提到的p 一系统为基础开发的。 f - 系统使用新的w e b 报表前端，客户能够自定义一个包含多容器( c o n t a i n e r ) 的e x h i b i t 。每一个容器为选择和显示数据提供了一些选项。另外，现存的b 系 统中的e x h i b i t 对象以及相关的选顼，会在将来逐渐被增加到卜系统中。值得注 意的是这个报表应用程序是独立于b 系统的；在初始的阶段，f 一系统中的e x h i b i t s 会独立地在w e b 应用程序运行，而在后续阶段，f 一系统中输出的报表和标准报表 会被合并到同一个w e b 应用程序中。而且它们产生的内容也可以合并到同一个p d f 中。 图2 一if 系统的主页 2 2 基金报表系统的架构 2 2 1 架构上的约束 以下是一些会影响f - 系统设计的因素： j 2 e e - 1 e b 应用必须运行在符合j 2 e e 标准的w e b s p h e r e 应用服务器5 x 上 现存的数据库表所有对现存数据库表的访问权限必须为只读 3 浙江大学硕士学位论文第2 章基金报表系统 现存的数据库0 r a c l er d 卜这将会影响应用程序的性能 2 2 2f - 系统的框架 卜系统是基于j 2 e e 架构开发的，主要的数据交互以m v c 设计模式实现。下 面的图例是f 一系统及相关模块的一个主要关系示意图： 图2 - 2f 系统的架构示意图 1 在w e bc o n d o 中，用户通过w e b 浏览器向w e b 服务器发送h t t p 请求 2 w e b 服务器依据s i t em i n d e r 验证用户的合法性，然后将请求根据负载平 衡调度的要求转发到相应的w e b s p h e r e 应用服务器。 3 j s p 读取用户的请求，然后让s e r v l e t 来处理这个请求，此时s e r v l e t 会 调用e j b 进行后端的事务处理，调用a t t u n i t y t y p e3 j d b c 驱动访问0 r a c l e 数据库 4 当j s p 收到用户请求运行报表的时候，请求转发至s e r v l e t ，然后s e r v l e t 负责与e j b 进行交互。 5 e j b 将会准备好相关的参数然后通过s a sb ij a v aa p i 异步调用s a s 存储 过程。 6 s a s 存储过程通过s a s c o n n e c t 从数据库读取数据，然后进行相关的计算， 再生成报表单元存储到文件系统中。 7 e j b 会一直监视文件系统是否生成了报表单元，并把当前的进度反馈给用 户。 8 当用户请求打开一个己完成的报表时，j s p 会将报表单元装配好并将最终 的报表结果发送到用户的w e b 浏览器上。 4 浙江大学硕士学位论文 第2 章基金报表系统 图2 3f - 系统架构的基础组织示意图 2 2 3f 1 e x i b l er e p o r t i n g 的页面流程 下面的图表从全局上展示了f 一系统的流程： 图2 4f 系统的全局页面流程 2 3f _ 系统的新特性 2 3 1 能包含四个容器的e x h i b i t 过去，所生成的报表只能包含一个e x h i b i t ，这样用户就只能看到基金过去 5 浙江大学硕t 学位论文 第2 章基金报表系统 某一方面的业绩。如果用户想： 看到基金在几个方面的表现情况 与其它基金进行某一方面的比较和评价 用户就不得不反复进行生成报表的过程，这将会非常令人厌烦。然而，在f 一 系统中，我们让一个e x h i b i t 包含四个容器以供用户灵活选择。用户可以使用全 部四个容器，或者只用其中几个。所生成的报表由四个容器组成。 在近期，这项特性将会进一步得到加强，以提供更大的灵活性。我们会提供 更多的容器选择，并且每个容器的尺寸都可以由用户来调整以适应用户的特殊需 求。 图2 - 5f - 系统中含四个容器的a 【h j b i t 2 。3 2 能改变e x h i b i t 中使用的参数 在f 一系统中，对于每一种容器类型，有少量的参数需要用户设置这些参数 主要有两组： 外观参数 。公共参数：容器的标题，标题对齐 。特定的参数：列选择，行选择等等 计算参数 例如时间周期( 计算周期p e r i o d ) ，评价( 所比较的对象) 等等。 6 浙江大学硕t 学位论文 第2 章基金报表系统 图2 石参数设置的w 曲页箍 2 3 3 更改原始e x h i b i t 的外观和风格 允许用户更改e x h i b i t 中的标准颜色和字体，从而让用户获得不同的体验， 这也是f - 系统的设计目标灵活。 2 4p - 系统与f - 系统之间的比较 老系统与新系统之间有如下差别： f 一系统是一个独立的性能报表系统，使用户从b 系统繁琐的工作中解脱出 来 f 一系统提供了一个友好的基于w e b 的界面，系统更稳定，响应速度更快。 f - 系统提供了报表预览功能，用户在正式打印之前就可以看到报表的样 子，所见即所得。 f 一系统允许用户可以自定义报表的页眉页脚，旧系统则没有这样的功能。 新旧两个系统生成的报表样式也是不一样的。以下分别是新旧两个系统生 成的报表。 7 浙江大学硕上学位论文 第2 章基金报表系统 图2 7f 系统报表 图2 8 p 系统报表 综上所述，f 一系统比p 一系统更灵活。 8 浙江人学硕士学位论文 第2 章基金报表系统 2 5 本章小结 f 系统是在p 系统基础上而来，改进了p 系统的报表功能。f 系统提供了更 灵活的功能，更稳定的系统，更快的响应速度。 目前f 系统所提供的c o n t a i n 盯种类仍有限，在不久的将来，会逐渐添加， 并加强f - 系统的其他功能。 9 第3 章j a v a 性能问题 3 1j a v a 性能介绍 j a v a 已经被证明是一个非常有吸引力的开发和部署商业应用的平台。j a v a 平台具有非常容易理解的面向对象特性，优越的程序安全性，自动高效的内存管 理技术，这些特点为开发可靠的商业应用系统提供了个坚固的基础。此外，弘v a 运行环境所具有的平台独立性也保障了用户的商业投资，这对信息技术管理者也 非常有吸引力因为这些企业应用计算通常有一个非常长的生命周期。高级的 j u s t i n - t i ( j i t ) 编译技术，内存管理以及垃圾收集机制是j a v a 程序在初始化 运行时性能较低的原因，但这也是j a v a 技术的优点。今天，j a v a ( 虚拟机) 吸收了各个平台的优点并不断优化，已经能够发挥出最新的硬件平台和操作系统 的性能。 当j a v a 在开发服务器端应用程序中使用得越来越广泛的时候，j a v a 的标准 化，稳健性，可扩展性应用程序支持框架的问题就变得越来越重要。j a v a2 企业 版本( j 2 e e ) ”1 是一个专门针对应用服务器的，定义严谨全面的规范，它设计了一 系列系统软件以减轻开发者的负担，这些系统软件包括组件模型，生命周期，对 象模型，数据库访问，安全，事务集成和多线程安全等。 1 0 浙江大学硕士学位论文 第3 章j a v a 性能问题 图3 1 性能优化需要考虑的三个层面：系统层面，应用层面以及硬件层面 当一个应用系统从开发阶段进入产品阶段的时候，性能问题就开始变得格外 重要。应用系统的性能不仅要达到能够进行部署的严格要求，而且要能够随着不 同的使用情况和用户的要求而相适应地变化。性能优化在这种环境下会受到很多 因素的影响，因此是一项非常艰巨的任务。 3 2 系统层面的性能 在系统层面，我们认为性能上的瓶颈通常出现在：输入输出( i o ) ，操作系 统和数据库，我们会在下面讨论些能够克服这些瓶颈的技术。 软件按其处理请求的方式可以分为批处理和交互式处理两类。对于前者，吞 吐量，就是一段时间内所完成的工作量，是主要需要关心的问题。而在每个单位 工作上所花的时间并不是主要考虑的问题。 而对于交互式处理软件，系统的响应时间则显得非常重要，它比吞吐量更有 衡量意义。 塑垩查兰堕主兰堡丝塞 兰! 兰塑翌堡壁塑垦 架构一个性能优越的系统是一项艰深的工作，为了能让性能优化再优化还需 要做很多深入细致的工作。 除了了解系统是以批处理方式还是以交互式方式处理请求的，了解系统硬件 以及软件组件组成，这对于达至优化目标也非常重要嘲。 所有的系统都可以看作是一个包含了各种各样组件的网络，这些组件相互交 互来执行具体的事务处理操作。在j a v a 企业应用中，这样的组件可以是硬件， 软件，或者是两者的组合。举个例子，网络或者磁盘子系统可以看作是一个硬件 组件，而应用程序就是软件组件。数据库服务器则是两者的结合。将整个系统看 作是一个基于组件的网络是非常有用的，这样便于我们找出系统中的性能瓶颈。 为了排除瓶颈，常使用多处理，即让系统组件在同一时间处理多个请求这 将会大大改善组件的性能。进行多处理的两种方法是流水线操作和并行处理。 流水线操作的基本思想是将处理一个请求的工作分成多个部分，当系统的某 个计算单元在负责处理请求的工作的其中一个部分的时候，另一个计算单元可以 处理请求的另一部分工作，从而能够最大限度地利用系统的资源。流水线主要用 于增加系统的吞吐量，但是它对于处理单个事务所花费的时间是不会有影响的。 并行化是将多个系统资源集中起来处理同一个任务，这样任务会完成的更 快。这样做的主要作用是减少系统的响应时间。通常开发者利用多线程机制以软 件的方式实现这一目标。而硬件上的实现方法包括建立镜像硬盘和多个网卡。 多数系统会同时采用两种多处理方案。 3 2 1 在系统层面提高性能的重要性 理论上讲，在没有任何性能瓶颈的系统里，每个系统的组件都会有同样的性 能行为和同样的容量。也就是说，在实际情况下，每个系统都会有性能瓶颈。 在系统层面，设计的目标是使性能瓶颈只存在于开发者能控制的应用程序的 层面上。这样开发者可以在应用程序层面来改善系统的性能。如果瓶颈是存在系 统别的地方，那么应用程序层面中对性能的大幅改善也只会对系统的整体性能有 很小的影响。 ， 3 2 2 吞吐量曲线图 画出吞吐量曲线图对于理解系统层面的瓶颈非常有价值。这还可以帮助找出 潜在的解决方案。图3 2 展示了一个吞吐量曲线图，它揭示出了系统吞吐量，响 应时间和应用服务器的c p u 利用率与注射比率( 发送到系统的请求数时间) 的 塑坚叁兰堡! 兰竺丝兰 苎! 兰竺! 丝璧塑望 函数关系。 图3 2 吞吐量曲线图，它表明了系统吞吐量 响应时间和应用服务器的c p u 利用率 与注射比率的函数关系 3 2 3 系统层面性能优化的目标 通过系统层面的性能调节，应使应用服务器的c p u 占用率达到饱和( 例如， 9 0 l o 瓣利用率) 。当系统达到最大的吞吐量时而c p u 占有率并没到达饱和，表明 系统存在性能瓶颈，例如i o 发生竞争造成过多的i 0 访问时间，过多的同步操 作，或者是不恰当的线程池配置和数据库配置。 当应用服务器的c 踟达到饱和时，表明在应用服务器之外已经不存在系统层 面的瓶颈了。这个时候测定的吞吐量反映出当前系统层面调节所能达到的最大容 量。 通过校准应用服务器的一些参数，调整垃圾收集处理参数以及增加应用服务 器到集群中会进一步改善性能。 使应用服务器的c p u 利用率达到饱和是性能优化的目标。 浙江大学硕上学位论文第3 章j a ”性能问题 3 2 4 系统层面的调节技术 一个系统是由很多相互连接的组件组成的，例如数据库，磁盘，网络等等 很多组件的响应时间都会随着吞吐量的增长而呈指数增长。换言之，响应时 间的增长速度比吞吐量的增长速度快。因此，需要仔细优化这些组件，以使组件 中不用处理太大量的工作，从而达到降低响应时间的目的 如果说响应时间是衡量应用程序优劣的一个重要方面，那么就必须要求系统 保持在较低的资源利用率上，否则，稍高的利用率也就可以接受。确切的资源利 用率的域值由很多因素决定。应该由多次有针对性的试验和一些负载测试得到。 像处理器利用率这样的关键的性能指标应当被监控。此外还需要监控内核中 耗费的时间。中断，系统调用的次数，页面失效，磁盘i 0 及网络利用率等。 3 2 5 数据库调节技术 企业应用中一个关键的组件就是后台数据库因为它除了能为系统提供关键 的持久数据存储服务和数据获取服务外，还提供了数据查询和报表应用程序。后 端的关系数据库通常是造成性能瓶颈的原因。因为它会带来大量的可能花费大量 时间的磁盘1 0 操作。因此，我们要格外重视数据库的物理设计和调试，以使性 能达到一个满意的水平。 最基本的一些考虑点包括将日志文件分开用专门的设备保存。因为日志文件 操作是以连续方式访问磁盘，而访问数据库表格则会随机读写，这样造成的冲突 会使性能大幅下降；充足的内存空间可以降低磁盘上外捧序操作次数；以及分配 足够的数据库内存缓冲( 但是要避免交换) ：仔细的定义数据索引，例如索引最常 用的，被选择次数最多的关键字，索引常在连接中使用的外键；此外使用一些磁 盘阵列技术( 例如i l a i d1 + o ) 来分散i 0 操作从而避免设备繁忙。 除了以上提及的技术，我还从工程角度研究了一些可能会造成数据库性能低 下的原因，我们应该尽量避免发生这些问题。 避免太过于复杂的搜索语句 太多的w h e r e ，o r d e rb y ，g r o u pb y ，s o r t 子语句会造成c p u 瓶颈 避免过大的数据库表 搜索整个数据库表会导致巨量的磁盘i o ，这会导致i 0 读取等待 避免过于频繁的更新数据或者每次更新过多的数据。这同样会造成过多 的磁盘i o 塑垩查兰堡! 兰竺堕兰 塑! ! 竺竺堡丝塑璺 3 3 应用服务器层面的性能 在应用程序层面，我们将会讨论应用程序的设计和应用服务器的调节。 3 3 1 应用服务器 应用服务器为开发和部署企业应用程序打下了坚实的基础。他们实现了丰富 的应用程序接口( a p i ) 和在j 2 e e 标准规范中制定的一系列功能。这将会有力的支 持多层结构应用程序的开发。 基于应用服务器的应用程序通常是由多个层次的结构组成的：客户层，w e b 界面层，业务层和企业信息系统层。客户层代表来自用户的服务请求，一般与用 户界面相关联。w e b 界面层提供了处理基于w e b 的表单和bs e r v i c e 的功能， 并且它可以动态的将返回的结果装配成h t m l 和或者x 札业务层常用于实现复 杂的计算，商业逻辑和商业规则。而企业信息系统层则包括后端基于关系数据库 的持久存储和一些遗留系统。 如图3 3 所示，应用服务器是以容器的概念建立起来的，一般位于j a v a2 标准版本平台( j 2 s e ) 的最顶端，包括了j a v a 虚拟机( j ) 和一系列的a p i 两 个基于应用服务器的容器分别是w e b 容器和e n t e r p r i s ej a v ab e a n ( e j 8 ) 容器。 w e b 容器常被用于支持基于w e b 的用户界面组件，例如s e r v l e t s 和j a v as e r v e r p a g e s ( j s p ) 。e j b 容器用于支持商业组件，包括s e s s i o nb e a n s ，e n t i t yb e a n s 和消息驱动b e 卸。s e s s i o nb e a n 提供了二种途径访问独立的商业组件： 有状态会话b e a n ，在几个不同的服务请求中，保留状态信息； 无状态会话b e a n ，适用于单个服务请求与其它的请求相独立，并且不要 求保留状态信息时； 实体b e a n 通过与数据库的连接提供持久化服务。 1 5 图3 3 基于服务器的两个容器，分别是w 曲和e j b 容器 消息驱动b e a n 的用处是异步消息处理，能用于实现商业组件。 除了提供a p l 支持核心容器外，应用服务器还提供了额外的a p l 支持例如 命名和目录服务( j n d ij a v a n 锄i n g a n dd i r e c t o r y ) ，数据库联接服务( j d b c ) ， 消息服务( j m s ) ，) ( i i l 处理( j a x p ) ，事务处理( j t s ) 。以及与遗留系统的连接。 为了为这些全面广泛的功能集合提供运行时支持，应用服务器还需要实现很 多关键的服务，例如状态管理，生命周期管理，线程池，事务，安全，持久性， 容错和负载平衡的管理。典型的应用服务器的例子有b e a 的w e b l o g i c ，i 阴的 w e b s p h e r e “1 和0 r a c l e 的9 ia s 吲等商业应用服务器。除此之外，还有很多开源的 应用服务器实现，例如j b o s s 州和j o n a s 0 1 。更多关于j 2 e e 和应用服务器的信息 在嘲【”1 和1 中提及。 3 。3 2 应用程序设计 应用程序的设计是影响系统性能的重要因素。一个设计良好的应用程序不仅 能在一开始就避免很多性能上的缺陷，而且在系统生命周期里的性能测试阶段也 会较容易维护和修改。 很多优秀的j 2 e e 应用程序开发实践都是建立在设计模式上“引设计模式 为应用程序设计提供了一个良好的出发点。设计模式提供的是在软件开发中常会 遇到的功能需要和使用场景的设计方法，所以对于程序开发是一种很好的参照。 一些设计模式对性能有着正面影响，且使系统易于维护和更模块化。 1 6 浙江大学碗i 学位论文第3 章j a 性能问题 下面我们研究几个设计模式，它们都能带来显而易见的性能提高。 3 3 2 1 价值对象 一些实体包括了一组永远会被集体一起访问的属性。通过远程接口访阀，每 次只访问实体中的一个属性会引起过大的网络流量和大量的延时，并且会花费服 务器不必要的资源。于是我们把相关的属性归组，形成一个新的类。这个类作为 远程商业方法的返回类型。客户调用粗粒度的商业方法后得到这个类的实例作为 返回类型，然后在本地访问这个对象内的细粒度属性在一次对服务器的访问中 就获取多个有用的价值会降低网络流量并使服务器的资源使用率最小化。 3 3 2 2 会话门面 很多商业流程都要对商业类进行复杂的操作。一个商业类通常会被卷入好几 个商业处理单元和工作流的工作中。设计到多个商业对象的复杂处理会导致在这 些类之间造成紧耦合，从而影响灵活性和设计清晰度。 会话门面模式定义了一些高层的商业组件，它f 】对低层次商业组件问的复杂 接口进行集中处理。一个会话门面为应用程序的功能或子集提供了一个单一接 口。它同时也降低了低层次商业组件与其它组件的耦合度，使设计更灵活和更易 于理解。 通过远程接口进行细粒度的访问是不明智的。因为这样增加了网络流量也增 加了响应时闻。下面图3 _ 5 为使用会话门面之前和之后的示意图，图中展示了一 个客户通过远程接口访问细粒度商业对象的序列图( s e q u e n c ed i a g r 绷) 。多个 细粒度的调用导致了大量的网络流量，也导致性能下降。 1 7 b e f o r e a f t e r c e n t；s e s s i o n e n t j t ye n t i t y o b j e c t ； b e lb e 柚lb e 柚2 d 0 1 1 1 i s 0 d o t h a r 0 d o m o r e o n 吼w o r k b o u n d a r v n ts e !订口ns e s诅口ne n lt ye n e c t隐a d eb em lb e n lb d 0 0 d o r h i s 0 。 d o t h a t 0 n a 巾w n ad o m o 怕0 图3 - 4 使用会话门面之前和之后的序列图 如图3 5 中的”a f t e r ”图所示，因为所有对细粒度商业对象的访问都是通 过本地进行的，采用会话门面模式会降低网络流量和减少响应时问。会话门面就 如同一个中间调度层，将商业对象之间的a p i 进行解耦。 3 3 2 3 服务定位 企业应用程序需要一个有效的方法来查找服务对象以访问分布式的组件。 j 2 e e 应用程序使用j a v a 命名和目录接口( j n d i ) 来查找企业b e a n 的h o m e 接口， j a v a 消息服务( j m s ) 组件，数据资源，连接和连接工厂重复的查找代码会使代 码变得难以理解和维护。而且，不必要的重复代码也会产生一些性能问题。 服务定位器模式集中处理了分布式服务对象查找方面的工作，提供了一个集 中控制点。并且会像有缓存一样，减少一些重复的查找。 3 3 2 4 胂s 一个常用于改善企业应用程序响应时间的策略是使用异步消息。通过使用消 息驱动b e a n 来实现或者直接使用j m s 技术。异步消息适用于不需要及时处理的， 塑翌盔兰堕主兰竺堡苎至! 童塑翌壁堡塑璺 响应时间较长的商业操作，例如定单提交或是文档提交“ 3 3 2 5 其它的指导原则 除开设计模式外，还有一些设计原则能有助于提高系统性能，例如： 企业j a v a b e a n ( e j b ) 的h o 【i l e 接口和数掘源应该被放入缓存，以避免j n d i 重复查找。 应该尽少使用h t t p 会话( s e s s i o n ) 来保存状态信息。 j a v as e r v e rp a g e s ( j s p ) 的默认状态就会创建h t t p 会话。这应该在不需 要的时候进行改写( 如，s e s s i o n = ”f a l s e ”) ，以避免浪费会话资源。 数据库连接在不再需要使用的时候应该及时释放。未释放的连接会导致 资源泄漏问题。 不使用的有状态会话b e a n ( s t a t e f u ls e s s i o nb e a n ) 应该被删除。并 根据系统需要设置适当的空闲超时值( t i m e o u tv a l u e ) ，以控制有状态 b e a n 的生命周期以保护珍贵的系统资源。 3 3 3 应用服务器调试 一个好的应用设计是高性能系统的起点，但仅仅有这些是不够的。工作负载 仍然是影响性能的一个重要因素。这需要对应用服务器的配置进行一些专门的优 化。有很多参数以供调节来优化系统的响应时问和吞吐量。我们很容易通过一些 常见的应用服务器，例如黯b s p h e r e 应用服务器( 欺s ) 修改它们。这里给出的 有助于改进系统性能的参数列表，远远没有覆盖到所有参数。它们仅仅是调试企 业j a v a 应用性能的比较好的出发点。 3 3 3 1 设置线程池的大小 在达到性能的峰值前需要逐渐提高线程池的大小然而，不能把线程池的大 小设得过高，过高的数值会降低系统的性能。一个理想的数值取决于系统的工作 负荷。 3 3 3 2 数据库连接池 数据库连接池的大小应该等于，系统中可执行的线程数，这样执行中的线程 就不用等待数据库连接了。 3 3 3 3 预处理语句缓存 1 9 塑垩查堂堡! 兰竺堕兰 蔓! 兰苎竺堡丝塑璺 j d b c 预处理语句缓存会尽可能减少在数据库中重复解释查询语句。同样，缓 存的数值在达到性能峰值前应当逐渐增加。 对预处理语句进行缓存能够改善整个响应时间。因为，如果预处理语句已经 在数据库连接中存在的时候，那么应用程序就会在数据库连接中重复使用它们， 而不用重新创建一个新的预处理语句。 当应用程序在数据库连接中创建一个新的预处理语句，它会首先搜索连接中 的缓存，以确认和本预处理语句相同的s q l 字符串是否已经存在。如果找到了匹 配的信息，那么就返回缓存中的预处理语句以供使用如果没有找到匹配，那么 就创建一个新的预处理语句并返回给应用程序。当一个预处理语句被应用程序关 闭时，它会被返回到数据库连接的缓存中，而不是被完全关闭。 对于雅s ，保存在缓存中的预处理语句的数目可以在数据源中配置。每一个 缓存必须根据应用程序对于处理预处理语句的具体需求而做出调整。 3 3 3 4 会话超时设置 设置合理的会话超时( 即h t t p 会话失效的时间间隔) ；设置合理的空闲超时 秒数，以控制有状态会话b e a n 的生命周期，都有助于更有效地利用内存和其他 应用服务器的资源以改善性能。 3 3 3 5 设置初始时b e a n 池的大小 为初始时b e 8 n 池的大小设置一个合适的值，可以降低应用服务器启动时创 建e j b 的工作时间。 3 3 3 6 设置b e a n 缓存大小 为b e a n 的缓存大小设置合理的数值，从而使服务器不会过于频繁地钝化 b e a n 从而会减少文件1 0 操作，并提升系统的性能。 3 4 机器层面的性能 对于那些用静态编程语言如c 或c + + 开发的系统，机器层面的性能分析就是 根据硬件来对代码进行调试，这就使系统的部署工作变得复杂起来。然而对于 j a v a 来说，这里还多了额外的一层虚拟机。j v m ( j a v av i r t u a lm a c h i n e ) 有二个很重要的作用。第一，它使得j a v a 开发的系统能够很快利用最新的处理 器的优势，因为只要替换删的版本而不须重新编译整个系统就可以达到。第二， 为了达到高的性能标准，不再需要制定系统的不同版本来适应不同平台的差异 浙江大学硕上学位论文 第3 章j a u 性能问题 ( 如内存，c a c h e 的不同) ，这些硬件层面的不同都由j 硼来解决了，所以系统的 同一个版本就可以在不同的平台上通过调节j 来达到理想的性能。 3 4 1 刑内存管理 内存管理包括了对象分配，堆管理和垃圾收集。现代的j ，i i 对此都提供了几 种算法，有的j 产品向用户提供了几种算法，让用户自己选择合适的算法。选 择合适的算法很重要，因为通常来说，几种算法间有比较大的差异，从而也会导 致性能上较大的差异。不同的系统应根据自己不同的情况选择不同的算法。 3 4 1 1 对象分配 对于对象分配来说，需要考虑2 方面的问题：一个是对堆的管理，找出对象 可以被分配到的空间。第二则是把空间准备好以分配给对象。 其中第二条就需要把空间用o 重写，以准备好分配给新对象。在一个多处理 器的系统里，堆空间是在几个处理器之自j 共享的，所以为新对象分配空间应该是 一个同步的过程以保证其他处理器不会把对象分配到同一个空间中去。而同步操 作是费时的。为解决这个问题，一些j 产品为每个线程都分配了一部分堆空间。 这些被分配出去的堆片段被叫做t l a ( t h r e a dl o c a la r e a ) 对于清理空问以准备好分配给新对象的空间也存在几个算法。一个算法是当 t l 矗被分配出去时，就整个清空。这样傲的缺点是如果某一次为新对象分配空问 导致了一个t l a 的创建，那么处理过程就变得很缓慢。但是它的好处是，接下来 在这个新t l a 上分配空间就会比较快，因为整个空间已经事先被准备好了。此外 这样做还有一个好处就是提高了c a c h e 的性能，因为在清空整个空间的时候，就