论文部分内容阅读
一、引言
当前交通行业在开发、实施各种业务类应用程序时，往往有以下两大痛点。一是，程序的性能质量无法评估和考核。当前的现状是，使用方通常能够轻易确认功能需求是否已实现，但难以确认为实现这些功能，其后台的代码质量、结构质量是否合理，是否造成了其他方面的影响。从而使程序上线之后，因性能质量不佳，为使用者带来的风险和经济损失。二是程序所需的系统资源无法精确评估。程序投入真实运营之前，无法较为精确的评估程序所需要的各种系统资源的数量，从而使企业在部署这些程序时，要么资源过多造成了较大的设备浪费，要么资源不足，影响上线之后的系统性能。本研究通过一种程序优化检测方法及系统，对企业研发的应用程序进行质量评估，从而确保应用程序开发的质量和运营效果。
二、研究对象与特点
（一）研究对象
本次研究对象为交通行业，所选取的样本为神朔铁路所有已经上线的业务系统。
（二）研究特点
当前交通行业的各种业务系统其业务源端都是关系数据库，在数据库端借助数据库的性能视图，可以了解和掌握各种业务软件访问数据库的代码特征和程序所对应的数据结构特征，这些特征表现为数据库运行期间的各种性能统计信息，并从这些统计数据中导出获得性能量度，在紧急情况下，访问这些量度在与当前的情况做比较，通过查看这些过去的事件统计信息以给当前的问题带来启发，由于数据库管理员必须自始至终都密切关注可能会对他们所管理的各个系统的可用性或者性能有负面影响的潜在性能问题，因此不断采集相关统计数据对于性能分析变得很重要。
1. 借助数据库性能视图
本研究的基本方法是借助对关系数据库性能视图中数据的定期采集，通过分析、比对实现程序性能质量的评估。本研究正是借助这些保存在数据库内存性能视图中的原始运行数据，通工加工分析，实现业务程序性能质量的评估的。
2.以结果为导向
本研究是以结果为导向的性能评估方法。我们认为软件的性能质量评估的结果毫无疑问应当与最终结果，即用户体验相一致或相接近，因此，本研究中衡量性能质量的各个指标，反映的是以用户体验相对应的各个维度。
三、研究方案
我们通过两套数据采集和处理方式，实现对程序质量从基本面到具体问题点的追溯分析。
（一）第一套方案：周期性数据采集+三层数据加工方法
1.周期性数据采集
分为三个采样频率。周期性地采集数据库性能视图内的信息，如Oracle数据库的各种V$开头的性能视图，Sqlserver则多为dm_开头的性能视图，DB2多为sysibmadmin下的表或视图。这些信息包括且不限于数据库状态、数据库结构、性能指标计数器、等待事件、SQL执行统计、SQL执行计划等；通过周期性的收集整理数据库性能视图，从而对关系数据库端的应用程序质量、数据结构质量和配置质量进行分析。
2.三层次数据加工
将获取到的大量目标数据库的原始运行数据进行时间切片、特征箍选等一系列数据加工，采样到的原始数据最多会进行三轮的箍选和加工，从而为软件前端的功能显示准备好直观明确的呈现内容。
具体的采集和加工逻辑如下图：
（二）第二套方案：触发式采集+算法库数据处理
因扰企业的应用类问题有一个主要的特点是，问题的原因往往只在问题刚刚引发时能够追踪到痕迹，很多应用类问题事后是无法被重现和追溯的。因此，我们采用一套独创的触发式逻辑，以确保能在问题刚刚发生（或刚刚出现征兆时）追踪并保留下问题的根源数据。具体如下：
在第一种周期性采样中，每分钟会收集数据库的状态、性能计数器等信息，因为当系统出现异常时，首先会体现到这些状态和性能计数器上，这样当监测系统在发现收集到的指标有异常时，首先确定是何种指标异常，然后再根据事先设置好的程序逻辑，立刻针对性的采集与这种异常相关的程序运行信息。这里提到的“事先设置好的程序逻辑”，在于我们在本研究中专门为多种已知的、不同问题，分别准备一套不同的程序处理逻辑，我们将所有这些不同程序处理逻辑的集合，称之为算法库，以应对不同问题的不同处理方法。
简单来说，整个触发式采集+算法库处理逻辑大概分為三个步骤：
步骤1：借助第一种方法周期性采集中的短周期采集，如每分钟一次扫描数据库性能视图中的各项性能计数器和状态信息。
步骤2：如果在短周期性采集中，一旦发现某一数据库的性能计数器或数据库状态信息异常，则触发针对这类异常问题信息的收集和处理。
步骤3：这类异常问题具体的数据收集方式和数据处理方法将根据事先存放在软件算法库中的逻辑进行。
步骤4：算法库的作用不光是数据采集与处理，还包括针对具体问题的数据个性化展示，不同的问题以不同可视化方式进行呈现。
四、研究结果
根据以上两套研究方案，我们对神朔铁路各个业务系统进行程序质量评估以及具体问题的详细分析，以下是本次研究得到的信息：
关于本次研究得到的信息，我们对主要问题进行说明介绍：
（一）应用等待
例如在TGIS系统中，当一个客户端系统试图更新一行数据时，另一个客户端系统正在更新同一行数据，这时，后发起的这次更新请求就必须等待前者完成后才能进行，这就产生了应用等待，在交通管理系统中，出现极短时间的应用等待可以允许，但我们认为如果应用等待大于逝去时间的5%，对交通系统的影响就非常明显示了，系统响应慢，客户的响应时间过长，造成整个业务无法高效运行。通常优化的方式是確定造成应用等待的具体程序和具体语句，在逻辑允许的情况下通过修订代码、增加系统资源、规范操作等方式避免类似问题再度发生。
（二）硬解析
Oracle数据库中的一个指标hard Parse，这个值高，意味着一些常用的程序SQL语句没有使用绑定变量，而各种交通管理系统均为业务系统（OLTP），意味着这些系统中大量运行的都是逻辑类似的执行请求，当使用绑定变量时，同一逻辑的执行请求只需要解析更一条执行计划，而当没有使用绑定变量时，同一逻辑的执行请求，请求有多少，就会产生多少执行计划，这就是大量硬解析的产生原理，这个过程中会占用大量的CPU和内存资源，通过测试我们认为在交通管理系统中每秒硬解析值在15以内是比较合理的，如果更高业务响应时间将明显变慢。通常优化的方式是找到这些造成硬解析高的语句，在不需要修改语句逻辑的前提下，更改语句的写法，使之运用绑定变量。
（三）登录数
这个数值取决于程序的工作任务是否采用了短连接设置，例如在调度系统中，一列火车的调度安排任务是分解为多条SQL语句去执行的，有经验的开发人员会将代码设置为在开始任务时连接数据库，任务语句全部处理完毕后再断开数据库；但如果开发人员将代码设置为每执行一条SQL语句就登入登出系统一次，就会产生大量的系统登录行为，这时无论系统的硬件配置有多高端，在大量用户访问时都会感觉系统响应慢，业务处理时间过长，通过对于多个交通系统的长期测试，我们认为每秒登录数<15是相对于各种交通管理业务系统最合理的指标值。通常优化的方式是确定具体使用短连接的任务，在逻辑允许的情况下修订其连接方式。
（四）并发等待
开发人员可以在代码中指定让一个处理任务以并发的方式进行处理，以起到加快处理时间的目的，但并不是所有的处理任务都适合于并发处理，有些任务的处理有明确的顺序逻辑，这种任务被设置为并发处理时，先处理完成的子任务就被迫要等待其他子任务完成才能往下执行，这种等待事件就是并发等待。并发等待产生的原因，一是如上所述的程序逻辑不适用并发的地方用了并发，二是程序部署的系统条件太差，资源不够，造成较多的并发等待。通常的优化方式是根据以上的并发等待两个原因，通常优化方式一是通过观察代码段的逻辑，看是否需要去掉或减少并发度，二是增加系统资源。
五、结语
根据研究结果，我们最终选定反映程序性能质量各个核心性能指标的推荐值，以此来监测和确保业务系统的程序质量和部署质量始终是最优的。如下表所示：
本次所有研究是在神朔铁路的已上线业务系统之上完成的，因此，我们认为本研究的结论，这种程序优化检测方法，首先适用于神朔铁路，其次，我们认为该方法也适用于与神朔铁路业务特征类似的其他企业，即整个交通行业，可为交通行业业务性能质量提升提供参考。
业务程序的性能质量评估和考核是软件行业的集体痛点，也是未来软件行业必须攻克的重要课题。随着大数据技术的飞速发展，将会有越来越多的软件细分领域，通过程序优化，构建起业务程序质量评估体系，助力软件质量实现质的飞跃。
作者单位：国家能源集团神朔铁路分公司