论文:论软件的性能优化设计
文章目录
- 论文一
- 摘要
- 正文
- 总结
- 论文二
- 摘要
- 正文
- 总结
论文一
摘要
本人2022年有幸参加了中国石油集团的高性能数控测井系统项目的开发研制工作。该系统是在当前测井成套测井装备的基础上,为了满足高精度,高性能,高效率的要求开发的测井系统。该系统由井下成套仪器,测井遥测系统,测井地面系统,测井软件系统,测井解释评价系统等子系统组成。本人在其中主要是负责测井软件系统的分析、设计以及部分开发任务。作为整个系统控制核心的测井软件如何才能保证有整个系统的高性能和高可靠性呢?本文从系统优化、程序设计优化两个方面来详细讨论如何提高整个测井软件系统的性能。其中系统优化主要是通过调节软件运行环境来优化软件性能,程序设计优化主要从程序架构设计、语法、内存管理、输入输出等方面来讨论如何采取措施提高软件的性能。
正文
随着当前石油测井技术的发展,为了能更快,更好的得到储层地层信息,解决目前国内测井系统不统一,测井精度不高,效率低下的缺点,2004年1月中国石油集团公司科技局成立了高性能数控测井系统项目,目的是为国内测井行业提供一个从井下到地面以及解释评价的整套测井系统。系统的设计目标是一次测井,取得所有合格资料,并且能保证60井次的免维修率。整个系统由井下成套仪器,测井遥测系统,测井地面系统,测井软件系统,测井解释评价系统等子系统组成。我主要是负责测井软件系统的分析,设计和部分开发工作。
整个测井软件系统完成三个主要任务:测井数据的采集、测井数据的工程值计算、测井过程的监控。对应于这三个任务,整个系统分为三个系统层:数据驱动层(简称前端),数据处理层(主控)和表象管理层(后端)。数据驱动层的主要目的是封装地面系统和井下遥测系统,为数据的上传和命令下达提供统一的接口。数据处理层的主要目的是按每种仪器的刻度算法计算测井原始数据。表象管理层则负责测井数据的表象处理,主要是曲线和图像的显示与绘图。系统前端运行在Vxworks系统上,主控程序和后端显示程序运行在 Window2000系统中。前端主要是采用Tornado2.0开发,主控程序和后端显示程序采用 VisualC++2003开发。
由于测井软件系统负责着整个井下仪器的数据采集、仪器状态控制和测井资料获取。所以对测井软件系统的性能要求是非常高的。这主要表现在以下方面:
-
采集数据的完整性和正确性要求。由于目前井下仪器主要是通过100K的CTS遥测传输数据。要求每80毫秒采集一个完整的数据帧,由于仪器算法的特殊性,要求不能丢掉一帧,也不能采集错误的数据。这就要求数据驱动层有非常好的实时性和高可靠性。
-
数据显示和打印的实时性要求。由于井下地质情况复杂,为了保证测井安全以及测井数据质量,需要把测井的数据用曲线和图像的形式实时的显示和打印出来,以便于监控测井过程中井下的各种情况。
在软件分析设计和开发中,我们主要是系统优化和程序设计优化两个方面采取措施来提高软件的性能并取得了比较好的效果。下面我主要从这两方面进行讨论:
一、系统优化
系统优化主要是从测井软件运行的系统环境角度方面采用措施来提高软件的性能。由于Window2000操作系统的分时多任务系统,不能保证在80ms时间间隔内测井系统所要求的数据的完整性和正确性,所以我们采用VxWorks实时操作系统做为前端操作系统,运行数据采集程序,保证测井数据完整和正确。再通过网络连接到主控程序处理数据。为了保证系统网络数据传输的性能,采用千兆网,连接主控和前端。同时为了提高数据IO的响应速度,以及数据的可靠,采用scSI接口的磁盘阵列,提高数据的冗余度来保证系统数据的可靠性。同时,主机系统采用 Intel公司P4EE结构的多线程处理器,以及512M的DDR内存,来满足数据吞吐的要求。
二、程序设计优化
程序设计优化主要是程序设计优化主要从程序架构设计,语法算法和编译,内存管理,输入输出,软件测试等方面采取措施提高软件的性能。
1、程序架构设计
由于优化性能并不是个局部的过程,整个程序的性能提高必须在程序设计的开始阶段就给予考虑和规划,以设计良好的软件架构保证系统的良好性能。本系统采用三层系统结构,各层之间采用网络连接,实现松散的耦合。即使后端显示程序出现错误,也可以保证测井数据的完整和正确。同时引入组件对象的开发思想,把每个仪器的算法及控制都做成组件,并进行单独的测试,从而保证组件的正确性。采用这种办法不仅可以保证错误不会在系统的扩散,方便系统的调试。同时也可以利用以前成熟的仪器算法和控制代码,不会引入新的风险,提高系统的成熟度和可靠性。
2、语法算法优化和编译优化
在代码开发阶段,可以通过C+语法特点来优化系统,实现更好的性能。例如程序中大量的简单函数,为了提高运行效率,一般都采用内联函数的方式实现。在循环语句中,对各种情况进行度量主要通过把临时变量提出到循环体外,以及设置break和 continue 语言减少循环次数。在对大内存对象的参数传递上,例如仪器服务表结构,基本都是利用引用和指针实现,减少系统在堆栈上的内存分配。在仪器的刻度计算中经常要用到各种各样的算法,采用在保证测井精度的原则下,根据测井原理优化算法,尽量把一些递归和非线性的算法,转换为非递归的简单运算。同时为了充分发挥Intel CPU的功能,我们选择Intel的c++编译器,做为系统的编译器。Intel编译器对C++错误检查比较严格,这也保证了程序运行时的错误减少。在开发库的选择上,我们也采用了精练的ATL库开发仪器组件,使用WTL库开发用户的界面,同时使用STL库进行数据结构的实现。WTL库的使用使得我们可以抛弃传统的MFC动态库,减少程序的内存占用,也可以减少MFC常见的内存泄漏。STL是经过考验的C++标准库,实现的代码精练高效,管理方便。经过我们测试,同样的数据结构如队列、链表等,STL的实现比MFC的实现,STL的速度大约快10%。
3、内存管理的优化
内存管理对系统也很重要,在测井后端显示程序中,由于要分配大量的小对象,例如曲线和矩形等,通过分析性能测试数据,发现大量的小内存释放和分配,成为后端显示程序的速度瓶颈,所以我们采用自己的内存管理机制来减少系统的调用。首先根据测试数据度量,分配一大块内存给应用程序,然后通过管理这块内存,来满足程序对小内存块的请求和释放。如果内存不足的话,可以另外分配大块内存进行扩充。通过采用自己的内存管理机制后,再运行测试程序,发现程序的运行速度几乎提高了两倍。
4、输入输出优化
输入输出在系统的应用非常的多,特别是本系统采用三层网络的结构,其中的网络输入输出更加的重要。为了系统取的最好的性能,我们对前端和主控之间,主控和后端显示之间的网络通讯采用的都是多线程异步通讯的方式。与以前采用同步的方式对比,系统的速度提高了一倍,而且网络的故障也减少了很多,基本没有发生网络通讯中断,和数据掉帧的现象。在本系统中还有一个比较关键的技术难点,就是在如何在显示测井曲线和图像时同步连续的打印出显示的曲线。由于程序的实时性要求,程序在网络通讯和数据计算上已经消耗了大部分的资源。在这方面我们主要采取的技术手段的同步缓存显示数据,然后在安排一个单独的线程专门负责测井曲线的打印。经过测试,打印和显示之间只有一米左右的延迟。在200:1的通常测井显示比例下,这点延迟是在允许范围内的。
5、软件测试
测试并不能直接提高软件的性能,但是测试是提高软件性能的有效手段。一个好的测试工具更能提高工作的效率和质量。在本系统的开发过程中,我们主要是使用Rational公司的Purityplus工具进行测试。特别是用其中的Quantify工具进行系统性能测试,可以精确到代码行。通过它可以快速发现系统的性能瓶颈在哪儿,在哪儿耗时特别多,以及整个程序的远行时间。大部份的优化措施都是在测试过程中发现问题,然后在进行具体的优化。
总结
在采用以上各种优化措施后,软件系统的整体运行效率提高了50%左右,今年上半年,整个系统完成了系统联调。在下井实验过程中,在连接井下仪器、地面系统、和测井软件系统的基础上,软件运行可靠,保证了24小时不断电的情况下,数据帧掉帧率为0,误码率为0的好效果,得到用户的认可。
在整个系统的开发过程中,特别是对软件的性能优化,使我认识到软件开发中采用不同的设计和措施对软件的性能影响是很大的。好的测试工具对性能的提升有很大的帮助。在目前对软件性能要求越来越严格的要求下,只有在重视测试方法和测试工具使用的情况下,采用恰当的优化方法才能提高系统的性能。
论文二
摘要
本文结合我2008年在某人民银行实施的E户通电子转账系统的经历,就软件的性能优化设计进行了详细讨论。在系统的设计中针对实际应用环境主要从以下几方面对系统性能进行了优化设计:(1)选择当前成熟的三层C/S体系结构进行开发,以减轻数据库服务器的负担。(2)优化数据存取策略以降低系统运行对网络带宽的要求。(3)对客户端应用进行优化,如减少数据请求量、相关的处理利用多线程进行以提高系统的响应速度。通过以上优化设计,系统满足了企业百万级以上主题数据库处理要求,系统开发获得了成功。最后对系统中存在的不足进行了简要的总结,如未考虑查询的需求等等。
正文
近年来,各银行的信息化发展非常迅速,直接带动了银行中间业务的发展,银行随着多年的建设,已经在中间业务上建立了多个业务系统:如行内的通存通兑系统、定期借记系统、定期贷记系统等。由于这些系统都是由各银行的内部需求为主导建设的,只能支持单个银行系统内部的服务,难以实现银行间的服务,如以银行代收水费为例,如工行能代收水费,农行能代收电费,老百姓如果需要同时交纳水电费,就必须同时在这两家银行开户,十分麻烦。与此同时,银行因开展业务的需要,不得不与不同的收款单位联网,如水厂、电厂等,数量一多,银行也麻烦,安全控制越来越复杂,老百姓和银行都迫切需要进一步提升服务质量,实现银行中间业务联网,合理规划和利用银行的总体资源。为此,某人民银行领导经过研究决定于2005年利用自身技术力量开发设计E户通电子转账系统,作为银行间的电子转账业务支撑平台,实现7x24小时连续运行,满足银行间的跨行转账业务、定期借、贷记业务,并支持各银行在此基础上建设新的中间业务,作为架构设计师,组建了12人的开发队伍,全程参与了项目建设。项目从2005年7月启动,到2006年4月结束,历时9个月。
E户通系统涉及到与相关银行、相关企业的联网,支持批量和两种业务处理模式,支持定期借记(如定期代收水电费)、普通借记(如支票)、定期贷记(如代发工资)、普通贷记(如银行间转账)、银行柜面现金缴费(养路费等)、客户签约管理、网上业务受理等。除了满足以上的业务功能需求以外,还要应对如下性能方面的需求:系统的大部分工作都由分散全市的银行网点和联网企业受理,相应要求系统适合于分布式的应用环境并提供较好的性能,要能支持500个并发实时受理,必须在较小的网络带宽占用下完成日常业务处理,在使用64KB的DDN与系统连接,要求实时业务处理要在20秒以内完成。对于批量业务采取包处理机制,最大800笔一包,要求对保重每笔数据进行MAC验证正确后转发至相关银行,每包处理时间不能超出45秒,要求查询时,最迟必须在15秒内返回结果。资金清算,报表统计与生成工作等,不能影响其他业务的正常进行。
根据银行的业务和管理特点及上述提出的对软件性能方面的要求,在对软件的性能优化设计中和系统分析人员进行系统分析。因为该项目硬件投资较为宽裕,可以购买性能较好的服务器。因此,系统分析主要集中在数据库的设计和编码问题。对于500个并发问题,考虑到目前主要商业银行已经实现数据集中,各银行网点的交易数据是通过其管辖行发起,交易量会很多,但是银行总量不会很多,因此交易模式拟采用长链接模式,一方面是保证交易效率,一方面是保证交易可靠性,简化设计。由于是异构环境开发,最好采用成熟的应用服务器。对于实时交易时间问题,数据包的大小不是问题,关键是合理安排交易各区段的时间划分问题,考虑到受理方的处理能力,应至少保证有10秒的处理时间。对于批量系统的时间要求,主要在于两个方面:一是MAC验证的时间,二是对包内数据的分区和路由转发,其中后者是重点,需要在网络环境下进行验证,对于查询性能要求,考虑得到主要是对交易历史的查询,应适当分离当前库和历史库。
鉴于以上分析,在系统开发中做了以下的设计和安排。
首先选择了目前在数据库开发方面非常成熟的BEA公司的WEBLOGIC应用服务器模式,数据库服务器采用SYBASE EAServer。这样,系统具有良好的兼容性与可扩展性的同时,也为系统的性能改善提供了可能。
其次,在系统中根据业务处理分散在异地的特点,采用了三层C/S体系结构,通过三层C/S体系结构的设计可以将数据库的访问及业务处理逻辑移到应用服务器进行。由于系统应用特点,在应用服务器的设计中主要采取了长连接池和负载均衡的技术来提高系统性能。对于客户的新数据库连接首先去查找连接迟中是否有可用的连接,如果没有才建立之,否则直接利用连接池中的连接来处理客户端的请求,这样做可以有效降低系统因建立数据库连接而带来的性能影响,同时也可以较好的节约系统资源。针对系统主题数据库容量上百万以及日常业务处理繁重的情况,充分利用BEA WEBLOGIC应用服务器系统提供负载均衡的功能,如在业务处理高峰期系统将会自动通过调配服务器组的利用率,提高了应用服务器的响应能力。同时,在系统开发中采用了大量的存储过程对业务进行处理,既简化了业务逻辑变化带来的维护工作量,在提升数据库服务器的处理能力同时也提高了系统的性能。
第三,合理确定实时交易的时间区段,我方只是转发,处理的重点在于受理方,受理方可能有各种原因会导致时延。因此我们设定受理方有10秒的受理时间。若超过此时间,将会自动提示业务超时。为防止业务多次超时引起系统等待造成考虑下降,在程序中设置了阙值,对达到阙值的网店实现交易限制。
第四,对于批量交易处理问题,在研究所的大力支持下,找到了合适的网络MAC加密机制,能够满足系统对MAC运算的时间要求,要重点解决批量业务交易包问题。为此,需要第一手数据,模拟了一批数据,进行网络实际环境的测试。发现在数据包满载且包内数据目的地为不同银行的时候,在交易高峰期,很容易超时,一方面是受理银行可能超时,一方面是中心端可能超时。因此,经过仔细分析,确定以下组包原则:按照业务种类和单一受理行组包。业务发起方只需要关注业务包是否发送到中心,而不必关心是否到受理行,这样一方面可以简化中心端的操作,另一方面发起方等待时间短。
第五,合理规划设置查询服务,专门设置查询服务器,提供对当前日以前各交易的查询活动。这样,既可以满足客户的需求,又可以有效防止对交易的影响,客观上提高了数据库的处理能力。
第六,在客户端主要采取GUI方式与用户进行交互,使用多线程技术对用户输入进行处理,如用护输入完相关资料在提交时,系统利用线程来进行处理,这样系统主县城就不会因等待处理结果而停顿。另外,系统在查询中也大量使用了线程技术,系统首先利用线程对用户要求的资料进行查询,等结果出来后再交给主线程将结果显示出来,在显示浏览表格或用户查询结果时并不是一下将所有结果都从服务器提取过来,而是每次传输60条记录,屏幕上显示20条,还有40条暂时存储本地。如果用户继续查看则进行范爷操作以提高系统的响应速度。
另外,将批量业务处理、报表处理等大作业量尽量在系统闲时进行处理,一方面可以缓解业务高峰期的性能压力,另外还可以实现系统性能。
总结
通过综合利用以上技术,系统于2009年4月投入运行时取得了较好的效果,事实交易时间一般不会超过3秒,最长15秒,系统峰值处理能力远超过设计要求,经受住了5倍数据量的考验。批量交易数据处理一般在15秒内就得到了应答。客户查询交易一般在6秒左右的到应答,系统主要性能得到了设计要求,得到了银行和企业的好评。
尽管系统建设取得了成功,但是也看到了不足之处,设计中只考了满足联机交易均衡负载和提高性能,但是在实际应用中,发现银行客户对交易的查询是大量的,设计的前瞻性不足,余度不大,容易引发服务器堵塞,需要进一步考虑查询优化。
此次系统的顺利实施,为我在中、大型软件性能设计方面积累了较多的经验,为以后的工作提供了更好的帮助。同时,软件技术的日新月异也促使我要不断更新自己的知识结构,为应对不同体系结构的软件分析与设计做好准备。
更多内容请见: 备考系统架构设计师-核心总结索引
论文:论软件的性能优化设计
文章目录
- 论文一
- 摘要
- 正文
- 总结
- 论文二
- 摘要
- 正文
- 总结
论文一
摘要
本人2022年有幸参加了中国石油集团的高性能数控测井系统项目的开发研制工作。该系统是在当前测井成套测井装备的基础上,为了满足高精度,高性能,高效率的要求开发的测井系统。该系统由井下成套仪器,测井遥测系统,测井地面系统,测井软件系统,测井解释评价系统等子系统组成。本人在其中主要是负责测井软件系统的分析、设计以及部分开发任务。作为整个系统控制核心的测井软件如何才能保证有整个系统的高性能和高可靠性呢?本文从系统优化、程序设计优化两个方面来详细讨论如何提高整个测井软件系统的性能。其中系统优化主要是通过调节软件运行环境来优化软件性能,程序设计优化主要从程序架构设计、语法、内存管理、输入输出等方面来讨论如何采取措施提高软件的性能。
正文
随着当前石油测井技术的发展,为了能更快,更好的得到储层地层信息,解决目前国内测井系统不统一,测井精度不高,效率低下的缺点,2004年1月中国石油集团公司科技局成立了高性能数控测井系统项目,目的是为国内测井行业提供一个从井下到地面以及解释评价的整套测井系统。系统的设计目标是一次测井,取得所有合格资料,并且能保证60井次的免维修率。整个系统由井下成套仪器,测井遥测系统,测井地面系统,测井软件系统,测井解释评价系统等子系统组成。我主要是负责测井软件系统的分析,设计和部分开发工作。
整个测井软件系统完成三个主要任务:测井数据的采集、测井数据的工程值计算、测井过程的监控。对应于这三个任务,整个系统分为三个系统层:数据驱动层(简称前端),数据处理层(主控)和表象管理层(后端)。数据驱动层的主要目的是封装地面系统和井下遥测系统,为数据的上传和命令下达提供统一的接口。数据处理层的主要目的是按每种仪器的刻度算法计算测井原始数据。表象管理层则负责测井数据的表象处理,主要是曲线和图像的显示与绘图。系统前端运行在Vxworks系统上,主控程序和后端显示程序运行在 Window2000系统中。前端主要是采用Tornado2.0开发,主控程序和后端显示程序采用 VisualC++2003开发。
由于测井软件系统负责着整个井下仪器的数据采集、仪器状态控制和测井资料获取。所以对测井软件系统的性能要求是非常高的。这主要表现在以下方面:
-
采集数据的完整性和正确性要求。由于目前井下仪器主要是通过100K的CTS遥测传输数据。要求每80毫秒采集一个完整的数据帧,由于仪器算法的特殊性,要求不能丢掉一帧,也不能采集错误的数据。这就要求数据驱动层有非常好的实时性和高可靠性。
-
数据显示和打印的实时性要求。由于井下地质情况复杂,为了保证测井安全以及测井数据质量,需要把测井的数据用曲线和图像的形式实时的显示和打印出来,以便于监控测井过程中井下的各种情况。
在软件分析设计和开发中,我们主要是系统优化和程序设计优化两个方面采取措施来提高软件的性能并取得了比较好的效果。下面我主要从这两方面进行讨论:
一、系统优化
系统优化主要是从测井软件运行的系统环境角度方面采用措施来提高软件的性能。由于Window2000操作系统的分时多任务系统,不能保证在80ms时间间隔内测井系统所要求的数据的完整性和正确性,所以我们采用VxWorks实时操作系统做为前端操作系统,运行数据采集程序,保证测井数据完整和正确。再通过网络连接到主控程序处理数据。为了保证系统网络数据传输的性能,采用千兆网,连接主控和前端。同时为了提高数据IO的响应速度,以及数据的可靠,采用scSI接口的磁盘阵列,提高数据的冗余度来保证系统数据的可靠性。同时,主机系统采用 Intel公司P4EE结构的多线程处理器,以及512M的DDR内存,来满足数据吞吐的要求。
二、程序设计优化
程序设计优化主要是程序设计优化主要从程序架构设计,语法算法和编译,内存管理,输入输出,软件测试等方面采取措施提高软件的性能。
1、程序架构设计
由于优化性能并不是个局部的过程,整个程序的性能提高必须在程序设计的开始阶段就给予考虑和规划,以设计良好的软件架构保证系统的良好性能。本系统采用三层系统结构,各层之间采用网络连接,实现松散的耦合。即使后端显示程序出现错误,也可以保证测井数据的完整和正确。同时引入组件对象的开发思想,把每个仪器的算法及控制都做成组件,并进行单独的测试,从而保证组件的正确性。采用这种办法不仅可以保证错误不会在系统的扩散,方便系统的调试。同时也可以利用以前成熟的仪器算法和控制代码,不会引入新的风险,提高系统的成熟度和可靠性。
2、语法算法优化和编译优化
在代码开发阶段,可以通过C+语法特点来优化系统,实现更好的性能。例如程序中大量的简单函数,为了提高运行效率,一般都采用内联函数的方式实现。在循环语句中,对各种情况进行度量主要通过把临时变量提出到循环体外,以及设置break和 continue 语言减少循环次数。在对大内存对象的参数传递上,例如仪器服务表结构,基本都是利用引用和指针实现,减少系统在堆栈上的内存分配。在仪器的刻度计算中经常要用到各种各样的算法,采用在保证测井精度的原则下,根据测井原理优化算法,尽量把一些递归和非线性的算法,转换为非递归的简单运算。同时为了充分发挥Intel CPU的功能,我们选择Intel的c++编译器,做为系统的编译器。Intel编译器对C++错误检查比较严格,这也保证了程序运行时的错误减少。在开发库的选择上,我们也采用了精练的ATL库开发仪器组件,使用WTL库开发用户的界面,同时使用STL库进行数据结构的实现。WTL库的使用使得我们可以抛弃传统的MFC动态库,减少程序的内存占用,也可以减少MFC常见的内存泄漏。STL是经过考验的C++标准库,实现的代码精练高效,管理方便。经过我们测试,同样的数据结构如队列、链表等,STL的实现比MFC的实现,STL的速度大约快10%。
3、内存管理的优化
内存管理对系统也很重要,在测井后端显示程序中,由于要分配大量的小对象,例如曲线和矩形等,通过分析性能测试数据,发现大量的小内存释放和分配,成为后端显示程序的速度瓶颈,所以我们采用自己的内存管理机制来减少系统的调用。首先根据测试数据度量,分配一大块内存给应用程序,然后通过管理这块内存,来满足程序对小内存块的请求和释放。如果内存不足的话,可以另外分配大块内存进行扩充。通过采用自己的内存管理机制后,再运行测试程序,发现程序的运行速度几乎提高了两倍。
4、输入输出优化
输入输出在系统的应用非常的多,特别是本系统采用三层网络的结构,其中的网络输入输出更加的重要。为了系统取的最好的性能,我们对前端和主控之间,主控和后端显示之间的网络通讯采用的都是多线程异步通讯的方式。与以前采用同步的方式对比,系统的速度提高了一倍,而且网络的故障也减少了很多,基本没有发生网络通讯中断,和数据掉帧的现象。在本系统中还有一个比较关键的技术难点,就是在如何在显示测井曲线和图像时同步连续的打印出显示的曲线。由于程序的实时性要求,程序在网络通讯和数据计算上已经消耗了大部分的资源。在这方面我们主要采取的技术手段的同步缓存显示数据,然后在安排一个单独的线程专门负责测井曲线的打印。经过测试,打印和显示之间只有一米左右的延迟。在200:1的通常测井显示比例下,这点延迟是在允许范围内的。
5、软件测试
测试并不能直接提高软件的性能,但是测试是提高软件性能的有效手段。一个好的测试工具更能提高工作的效率和质量。在本系统的开发过程中,我们主要是使用Rational公司的Purityplus工具进行测试。特别是用其中的Quantify工具进行系统性能测试,可以精确到代码行。通过它可以快速发现系统的性能瓶颈在哪儿,在哪儿耗时特别多,以及整个程序的远行时间。大部份的优化措施都是在测试过程中发现问题,然后在进行具体的优化。
总结
在采用以上各种优化措施后,软件系统的整体运行效率提高了50%左右,今年上半年,整个系统完成了系统联调。在下井实验过程中,在连接井下仪器、地面系统、和测井软件系统的基础上,软件运行可靠,保证了24小时不断电的情况下,数据帧掉帧率为0,误码率为0的好效果,得到用户的认可。
在整个系统的开发过程中,特别是对软件的性能优化,使我认识到软件开发中采用不同的设计和措施对软件的性能影响是很大的。好的测试工具对性能的提升有很大的帮助。在目前对软件性能要求越来越严格的要求下,只有在重视测试方法和测试工具使用的情况下,采用恰当的优化方法才能提高系统的性能。
论文二
摘要
本文结合我2008年在某人民银行实施的E户通电子转账系统的经历,就软件的性能优化设计进行了详细讨论。在系统的设计中针对实际应用环境主要从以下几方面对系统性能进行了优化设计:(1)选择当前成熟的三层C/S体系结构进行开发,以减轻数据库服务器的负担。(2)优化数据存取策略以降低系统运行对网络带宽的要求。(3)对客户端应用进行优化,如减少数据请求量、相关的处理利用多线程进行以提高系统的响应速度。通过以上优化设计,系统满足了企业百万级以上主题数据库处理要求,系统开发获得了成功。最后对系统中存在的不足进行了简要的总结,如未考虑查询的需求等等。
正文
近年来,各银行的信息化发展非常迅速,直接带动了银行中间业务的发展,银行随着多年的建设,已经在中间业务上建立了多个业务系统:如行内的通存通兑系统、定期借记系统、定期贷记系统等。由于这些系统都是由各银行的内部需求为主导建设的,只能支持单个银行系统内部的服务,难以实现银行间的服务,如以银行代收水费为例,如工行能代收水费,农行能代收电费,老百姓如果需要同时交纳水电费,就必须同时在这两家银行开户,十分麻烦。与此同时,银行因开展业务的需要,不得不与不同的收款单位联网,如水厂、电厂等,数量一多,银行也麻烦,安全控制越来越复杂,老百姓和银行都迫切需要进一步提升服务质量,实现银行中间业务联网,合理规划和利用银行的总体资源。为此,某人民银行领导经过研究决定于2005年利用自身技术力量开发设计E户通电子转账系统,作为银行间的电子转账业务支撑平台,实现7x24小时连续运行,满足银行间的跨行转账业务、定期借、贷记业务,并支持各银行在此基础上建设新的中间业务,作为架构设计师,组建了12人的开发队伍,全程参与了项目建设。项目从2005年7月启动,到2006年4月结束,历时9个月。
E户通系统涉及到与相关银行、相关企业的联网,支持批量和两种业务处理模式,支持定期借记(如定期代收水电费)、普通借记(如支票)、定期贷记(如代发工资)、普通贷记(如银行间转账)、银行柜面现金缴费(养路费等)、客户签约管理、网上业务受理等。除了满足以上的业务功能需求以外,还要应对如下性能方面的需求:系统的大部分工作都由分散全市的银行网点和联网企业受理,相应要求系统适合于分布式的应用环境并提供较好的性能,要能支持500个并发实时受理,必须在较小的网络带宽占用下完成日常业务处理,在使用64KB的DDN与系统连接,要求实时业务处理要在20秒以内完成。对于批量业务采取包处理机制,最大800笔一包,要求对保重每笔数据进行MAC验证正确后转发至相关银行,每包处理时间不能超出45秒,要求查询时,最迟必须在15秒内返回结果。资金清算,报表统计与生成工作等,不能影响其他业务的正常进行。
根据银行的业务和管理特点及上述提出的对软件性能方面的要求,在对软件的性能优化设计中和系统分析人员进行系统分析。因为该项目硬件投资较为宽裕,可以购买性能较好的服务器。因此,系统分析主要集中在数据库的设计和编码问题。对于500个并发问题,考虑到目前主要商业银行已经实现数据集中,各银行网点的交易数据是通过其管辖行发起,交易量会很多,但是银行总量不会很多,因此交易模式拟采用长链接模式,一方面是保证交易效率,一方面是保证交易可靠性,简化设计。由于是异构环境开发,最好采用成熟的应用服务器。对于实时交易时间问题,数据包的大小不是问题,关键是合理安排交易各区段的时间划分问题,考虑到受理方的处理能力,应至少保证有10秒的处理时间。对于批量系统的时间要求,主要在于两个方面:一是MAC验证的时间,二是对包内数据的分区和路由转发,其中后者是重点,需要在网络环境下进行验证,对于查询性能要求,考虑得到主要是对交易历史的查询,应适当分离当前库和历史库。
鉴于以上分析,在系统开发中做了以下的设计和安排。
首先选择了目前在数据库开发方面非常成熟的BEA公司的WEBLOGIC应用服务器模式,数据库服务器采用SYBASE EAServer。这样,系统具有良好的兼容性与可扩展性的同时,也为系统的性能改善提供了可能。
其次,在系统中根据业务处理分散在异地的特点,采用了三层C/S体系结构,通过三层C/S体系结构的设计可以将数据库的访问及业务处理逻辑移到应用服务器进行。由于系统应用特点,在应用服务器的设计中主要采取了长连接池和负载均衡的技术来提高系统性能。对于客户的新数据库连接首先去查找连接迟中是否有可用的连接,如果没有才建立之,否则直接利用连接池中的连接来处理客户端的请求,这样做可以有效降低系统因建立数据库连接而带来的性能影响,同时也可以较好的节约系统资源。针对系统主题数据库容量上百万以及日常业务处理繁重的情况,充分利用BEA WEBLOGIC应用服务器系统提供负载均衡的功能,如在业务处理高峰期系统将会自动通过调配服务器组的利用率,提高了应用服务器的响应能力。同时,在系统开发中采用了大量的存储过程对业务进行处理,既简化了业务逻辑变化带来的维护工作量,在提升数据库服务器的处理能力同时也提高了系统的性能。
第三,合理确定实时交易的时间区段,我方只是转发,处理的重点在于受理方,受理方可能有各种原因会导致时延。因此我们设定受理方有10秒的受理时间。若超过此时间,将会自动提示业务超时。为防止业务多次超时引起系统等待造成考虑下降,在程序中设置了阙值,对达到阙值的网店实现交易限制。
第四,对于批量交易处理问题,在研究所的大力支持下,找到了合适的网络MAC加密机制,能够满足系统对MAC运算的时间要求,要重点解决批量业务交易包问题。为此,需要第一手数据,模拟了一批数据,进行网络实际环境的测试。发现在数据包满载且包内数据目的地为不同银行的时候,在交易高峰期,很容易超时,一方面是受理银行可能超时,一方面是中心端可能超时。因此,经过仔细分析,确定以下组包原则:按照业务种类和单一受理行组包。业务发起方只需要关注业务包是否发送到中心,而不必关心是否到受理行,这样一方面可以简化中心端的操作,另一方面发起方等待时间短。
第五,合理规划设置查询服务,专门设置查询服务器,提供对当前日以前各交易的查询活动。这样,既可以满足客户的需求,又可以有效防止对交易的影响,客观上提高了数据库的处理能力。
第六,在客户端主要采取GUI方式与用户进行交互,使用多线程技术对用户输入进行处理,如用护输入完相关资料在提交时,系统利用线程来进行处理,这样系统主县城就不会因等待处理结果而停顿。另外,系统在查询中也大量使用了线程技术,系统首先利用线程对用户要求的资料进行查询,等结果出来后再交给主线程将结果显示出来,在显示浏览表格或用户查询结果时并不是一下将所有结果都从服务器提取过来,而是每次传输60条记录,屏幕上显示20条,还有40条暂时存储本地。如果用户继续查看则进行范爷操作以提高系统的响应速度。
另外,将批量业务处理、报表处理等大作业量尽量在系统闲时进行处理,一方面可以缓解业务高峰期的性能压力,另外还可以实现系统性能。
总结
通过综合利用以上技术,系统于2009年4月投入运行时取得了较好的效果,事实交易时间一般不会超过3秒,最长15秒,系统峰值处理能力远超过设计要求,经受住了5倍数据量的考验。批量交易数据处理一般在15秒内就得到了应答。客户查询交易一般在6秒左右的到应答,系统主要性能得到了设计要求,得到了银行和企业的好评。
尽管系统建设取得了成功,但是也看到了不足之处,设计中只考了满足联机交易均衡负载和提高性能,但是在实际应用中,发现银行客户对交易的查询是大量的,设计的前瞻性不足,余度不大,容易引发服务器堵塞,需要进一步考虑查询优化。
此次系统的顺利实施,为我在中、大型软件性能设计方面积累了较多的经验,为以后的工作提供了更好的帮助。同时,软件技术的日新月异也促使我要不断更新自己的知识结构,为应对不同体系结构的软件分析与设计做好准备。
更多内容请见: 备考系统架构设计师-核心总结索引