提高数字化办公平台用户响应速度

(水利部小浪底水利枢纽管理中心，河南 郑州 450000)

1 引 言

互联网的用户心理调查报告指出，用户最满意的网页打开速度通常在2～5s,如果等待时间延长一倍，几乎所有用户都会把页面关闭。而对于一个水利电子政务类应用系统——OA系统来说，用户等待时间过长，会严重影响水利政务办公的效率，使政令和调令无法准确、高效的传递。

小浪底信息系统技术攻关QC小组成立后，运用科学的质量管理控制手段对小浪底信息化建设、运维过程中产生的各类技术难点进行攻关。小浪底OA系统改造完成上线试运行后，用户普遍反映系统页面打开速度较慢或很慢，经测试达4～15s，严重影响用户正常办公使用。因此，QC小组着力于提高数字化办公平台用户响应速度，于OA系统上线试运行的过程中同步开展活动。

2 现状调查

QC小组成员在不同时间、不同地点、不同使用环境下，使用谷歌开发者响应工具分别对用户打开首页、打开二级页面和打开公文工作流的响应速度做了量化测试。时间量化标准为“整个网页的资源全部加载完毕”。

接下来，在不同时间段进行了20次测试，结果为首页3.8～6.3s，二级页面5～9.8s，工作流6.9～14.9s；在不同地点做了15次测试，结果为首页4.2～5.6s，二级页面5.3～7.2s，工作流7.1～11s；在不同使用环境下做了10次测试，结果为首页4.6～7.5s，二级页面5.3～10.8s，工作流7～16.1s。现状调查结果见表1。

表1现状调查结果

根据以上调查结果可以发现，OA系统无论在何种情况下响应均较缓慢，这初步排除了大规模的用户因素，将问题重点收缩至系统自身。具体的症结还需在接下来的步骤中进一步推敲。

3 设定目标

经过小组成员认真分析、讨论，认为要做到让小浪底OA系统用户获得较佳的访问体验，系统响应时间不应大于4s；若要让用户获得最佳的访问体验，则打开时间最好在2s以内。

结合小浪底OA系统的软硬件架构情况、网络和机房环境情况、用户计算机使用环境情况等多方面因素，OA系统的用户响应速度预设提高至打开首页2s以内，打开二级页面、公文工作流3s以内。

4 原因分析

软件系统出现问题的可能因素众多。通过采用头脑风暴法，QC小组成员提出了30余条可能影响OA响应速度的原因。将这些原因中的要素进行信息关联、分类联想、系统判别后，初步整理为以下5个方面：用户原因、网络原因、服务器原因、应用系统原因和数据库原因。QC小组选用树状分析图对这5个方面进行更深入的分析。

4.1 用户导致的可能原因

小浪底OA系统的用户数量在1500个左右，每位用户使用的计算机新旧程度不一、品牌型号分布广泛，操作系统和浏览器也涵盖多种版本。针对9条用户方面的可能原因，通过下发调查问卷、采集日常运维信息、实地走访用户等方式，逐条归纳出该可能原因导致的后果，汇总统计出所占的用户比例。结果发现，有4条可能原因的用户数量占比较大(其中1条用户数超过50%)、1条可能原因的流程总数较一般OA系统来得更多。其余4条可能原因被排除，详见图1。

图1 用户原因树状分析

4.2 网络导致的可能原因

水利枢纽的建设特点决定了小浪底职工分布在几块地域工作生活，其间网络结构复杂、网间互联距离较长、节点与路由众多。QC小组针对3条用户方面的可能原因，逐条进行技术排查，均未发现可影响OA用户访问速度的因素。故这3条可能原因被排除，详见图2。

图2 网络原因树状分析

4.3 服务器导致的可能原因

服务器是应用系统运行的基础平台。小浪底OA系统2016年升级改造共使用5台国产服务器、2台磁盘阵列，其中两台应用服务器使用Rose HA软件实现高可用配置。QC小组针对6条服务器方面的可能原因，结合OA系统试运行期间的运维记录逐条进行测试，发现有1条可能原因的参数配置会产生I/O系统问题。其余5条可能原因被排除，详见图3。

4.4 应用系统导致的可能原因

小浪底OA系统为J2EE架构，满足SOA总线要求。前端使用国产CMS产品，后端使用国产工作流产品和权限管理平台，整体使用SSM框架+轻量级UI构建。PC前后端、移动端均通过国产SSO平台实现统一登录，并开放各类接口与其他系统交互。小浪底OA系统的二次开发量较大，所以是QC小组的重点检查方向。针对12条可能原因，小组成员通过多种软件测试方法进行逐一排查，发现其中4条可能原因所产生的数据指标相比正常B/S结构软件产品有所不足(其中1条指标较差)。其余8条可能原因被排除。详见图4。

图3 服务器原因树状分析

图4 应用系统原因树状分析

4.5 数据库导致的可能原因

小浪底OA系统使用Oracle 11g作为数据库，使用同门产品Weblogic作为中间件。在一套应用系统中，数据库设计得好与坏，会直接影响到系统整体的响应情况。QC小组在对8条数据库方面可能原因的详细检查中，发现有5条存在问题(其中3条可能存在较为严重的问题)，影响了数据库的查询效率和响应时间。其余3条可能原因被排除，详见图5。

5 确定主要原因

通过原因分析，QC小组得到了15条最可能的问题原因，见表2。

通过调查分析、现场验证、实地测试和运用软件工程中的白盒测试、回归测试、卸载测试、压力测试等方法，QC小组成员对15条最可能的原因依次枚举验证。以绘制直方图、散布图、推移图等方式，最终得到7条下面逐条简述这15条最可能原因的验证分析过程。

图5 数据库原因树状分析

直接影响OA系统响应速度的末端因素，详见图6。

图6 确定主要原因

5.1 用户浏览器版本过低

QC小组共访问了近300位用户，约2/3的用户在使用IE9版本或更低版本，小浪底OA系统最低适配的IE内核版本为9，过低的版本会造成页面出现兼容性问题，导致卡顿。因此，急需将用户浏览器都升级到一个较高的版本，此问题定为主要原因。

5.2 用户浏览器支撑组件版本过低

与用户浏览器版本同时进行的调查还包括小浪底OA系统的两个核心支撑组件：RiseOffice控件和RiseWord控件。接近90%用户的组件版本是V3，新的V5版本能更佳地适应浏览器，同时避免页面渲染时出现的奇怪问题。因此，急需将小浪底用户浏览器支撑组件都升级到新版本，此问题定为主要原因。

5.3 用户浏览器本身有问题或插件有冲突

在对用户进行调查的过程中，QC小组遇到了各式各样的浏览器或插件问题，但小组成员发现，大多数问题都可以通过“卸载有问题的插件”“重置浏览器”“升级浏览器到新版本”等方法快速解决。鉴于此问题大都可解，且解决方法与前述两条原因有所重复，此问题定为非主要原因。

5.4 用户使用了非IE内核的浏览器

小浪底OA系统的主要支撑控件不支持非IE内核浏览器(如谷歌、火狐等)，使用这类浏览器的用户会遇到控件长时间卡顿、无法加载等问题。QC小组成员在调查过程中发现，此类用户数量不多，并且在告知其“请使用IE浏览器打开OA系统办公”时，大家都能理解和接受。此问题定为非主要原因。

5.5 用户业务所需要的总工作流程过多

小浪底OA系统的工作流引擎需要在启动时一次性将所有流程加载完毕。经过QC小组统计，目前OA系统中共有177条在用流程、153条历史流程，启动后流程引擎占据了10.3GB内存空间。为了确定这些流程对服务器整体响应速度的影响，QC小组成员对流程引擎进行了由空载至满载的加载测试。

测试结果表明：随着工作流引擎加载流程数不断增加，其内存占用量基本成线性倍数增长，而服务响应速度的变化趋势不大，响应时间均在可接受范围内，此问题定为非主要原因。

5.6 Linux文件系统参数配置不合理

为避免资源消耗过大，OA系统所使用的Linux操作系统对同一时间用户、进程打开的文件数量有所限制。QC小组通过检查发现，在当前系统配置下，文件限制数为1024个，超限后偶尔会引发文件打开报错。经过模拟超限测试，QC小组确认此问题出现时不会影响到用户的响应速度，且通过简单修改系统配置即可解决，此问题定为非主要原因。

5.7 同时间大量用户并发访问

OA系统的并发访问量是重要的性能参数，QC小组选用Stress Testing压力测试工具作为并发访问量测试工具。测试结果显示，随着用户并发量从0增加至500，系统响应时间也随之成平稳线性增长，没有突然的指数性爆发。这说明用户的并发量增加不会导致OA系统出现严重响应拖延。

5.8 多数用户频繁请求特定资源

当用户访问应用系统时，页面资源按需加载到用户浏览器中。若同一时间请求某个较大资源的用户数过多，反复加载的过程会造成服务器性能下降。QC小组对大小超过300kb的公用资源进行了1h内同时被调用的次数最大值统计，结果显示，各类公用资源在用户加载页面时几乎都会调用，且加载次数相差不大，没有出现某个资源明显多于其他对系统响应影响较大的情况，确定OA系统单一资源同时调用169次属正常情况，此问题定为非主要原因。

5.9 页面布局不合理

当Web页面布局设计不合理时，用户端浏览器引擎会付出额外的开销来修正到正确的显示状态，或者出现渲染错误，导致卡顿。

QC小组将OA首页中所有大型资源逐个除去，再将CSS样式调整到最简状态，每次都进行页面渲染时间测试。结果表明，资源去除干净后，首页渲染时间与CSS最简状态的时间之差已经很小，页面布局对OA响应速度的影响已可忽略不计，此问题定为非主要原因。

5.10 页面动态资源和元素过多

如今越来越复杂的动态页面给服务器造成了越来越大的资源开销压力。QC小组成员首先测试了OA系统不同页面的动态资源请求次数，发现“资讯中心”的请求数最多，然后，又进行了一组针对性的“动态资源卸载与系统响应时间”对比实验。结果清晰表明，随着动态资源的卸载，资讯中心单页面的访问速度有了质的飞跃，从9.6s飞跃至1.6s。这说明了两点：ⓐ资讯中心页面的动态化程度太高，已经使服务器产生了较重负载；ⓑ去除不必要的动态资源，是提高页面访问速度的有效方法之一。此问题定为主要原因。

5.11 Oracle数据库连接数上限设置不足

数据库系统对同时访问某个实例的连接数不应限制得太小，QC小组首先检查了OA系统当前的Oracle数据库连接数，数值为150，然后QC小组模拟了在不同用户并发操作下，这个限制对SQL语句执行带来的影响。结果表明，当用户并发操作超过150时，超出部分即进入等待队列；且随着时间延长，部分等待的连接已超时丢失。小浪底OA系统目前用户数已过千人，按15%～20%并发计算，此限制确实会导致用户出现问题。此问题定为主要原因。

5.12 数据表没有建立索引或索引字段不对

数据表的索引若出现错误或没有建立，会大大影响库表查询操作效率。QC小组经过仔细检查，发现从原OA系统迁移过来的数据表，索引还使用的是老字段，目前已经不起任何作用。此部分表数量约占新OA系统的20%左右。通过SQL操作耗时记录可以看出，单表查询和多表联合查询耗时均远超正常SQL语句执行时间。此问题定为主要原因。

5.13 连接池设计不合理，连接不能及时关闭

Oracle等大型数据库使用连接池技术以增加数据库连接的复用性、可靠性和效率。但若应用开发者对连接池的设计不合理，就可能导致程序在使用完连接池中的资源后，无法及时关闭、归还资源，使连接池中的资源慢慢泄露，最后导致数据库拒绝任何新的连接请求。

QC小组对OA系统经过检查调试，发现了一个连接池问题。经修复后，证实此问题与OA系统的响应速度没有直接关系。此问题定为非主要原因。

5.14 SQL语句编写、优化不到位

SQL语句是任何应用信息系统的灵魂。一个好的SQL语句能大大提升数据的增删改查速度；反之，一个冗余的、含有隐性错误的SQL语句能将系统拖入消耗资源的泥潭中不能自拔。QC小组选用Oracle Automatic Workload Repository工具(自动工作负载信息库)进行资源消耗的Top10分析。经过仔细检查，找到6条执行时间大大超过正常状态的SQL语句。每一次的执行延迟加在一起，给系统响应速度带来了巨大的影响。经讨论，此问题定为主要原因。

5.15 单一表空间过大

若一张数据库表的体积太大，则对其进行SQL操作的耗时将成倍增加。对这些过大的表进行分区优化处理，是一种提高SQL执行效率的有效方法。QC小组成员对OA系统数据库中的表大小进行了仔细的梳理，发现从原OA系统中迁移过来的一张经常访问的附件表，体积已经高达10.5GB，执行联合查询的耗时远超正常水平。经讨论，此问题定为主要原因。

6 对策实施

6.1 最坏风险处置对策

一个应用信息系统的程序、模块、数据库等部分之间具有紧密的联系，对其进行任何更新、改造等活动，都有造成系统瘫痪的风险，且此类风险很难完全避免。因此，在对策实施前，QC小组首先采用PDPC图工具对实施过程中可能遇到的最坏风险进行了处置过程预估。详见图7。

对于OA系统来说，最坏的可能风险是在实施过程中出现OA系统瘫痪。当出现此类严重问题时，首先应尽快判断问题所属的分类，其次通过PDPC图中对应的流程模块针对出现问题的分类进行后续检查和处理。当问题处理妥当，流程进入绿色区域时，即可认为OA系统瘫痪问题已成功解决；当流程最终进入红色区域时，应及时做好灾难应对和解释上报，停止后续对策实施工作，查明原因并拿出切实有效的预防措施后再行继续。

6.2 主要问题对策实施

针对已得到的7条主要原因末端因素，QC小组按照5W1H的原则，经过讨论，按技术要求将原因分为3组，分别制定了目标和措施，并将每项措施落实到专人，同时规定了起止时间和活动地点。

6.2.1 用户浏览器版本过低

通过前面的活动过程，QC小组成员经过讨论，对此问题设立的目标是：将用户浏览器的版本升级至IE11。针对此目标，最有效的对策是通过逐级、分批地下载、安装来升级用户IE内核浏览器版本到Ver 11。根据小浪底OA系统用户分布地域广泛的特点，该对策在两地分几个批次实施，最终达到覆盖全用户的目的。

2017年11月5—30日，由QC小组成员牵头在郑州生产调度中心对用户进行了逐屋排查，共排查116位，发现问题用户47位；11月5—30日，由QC小组成员牵头在小浪底水利枢纽管理区对用户进行了逐屋排查，共排查422位，发现问题用户201位。以上均予以解决。

本次对策实施结果将小浪底各用户的IE浏览器版本统一为IE11。升级后的用户浏览器，打开OA系统没有再出现原来的各类奇怪问题和兼容性问题，没有卡顿和等待，用户使用体验得到了提升。

6.2.2 用户浏览器支撑组件版本过低

通过前面的活动过程，QC小组成员经过讨论，对此问题设立的目标是：将用户浏览器支撑组件的版本升级至Ver5。针对此目标，最有效的对策是通过U盘拷贝安装程序的方式逐级、分批地升级用户浏览器RiseOffice和RiseWord支撑组件版本到Ver 5.0.1.2。根据小浪底OA系统用户分布地域广泛的特点，该对策同样在两地分几个批次实施，最终达到覆盖全用户的目的。

因本条对策实施过程与“用户浏览器版本过低”对策类似，都需要对所有用户进行走访以及对用户浏览器进行维护操作，在技术上具有相似性，在时间和所耗精力上具有重复性。为了使本次QC活动具有更佳的经济性，经QC小组仔细分析讨论，决定本条对策与“用户浏览器版本过低”同人、同时实施。

5．独有的特异类宝石。昌乐不仅产出了世界公认的极品类型的蓝宝石，而且产出了大量珍贵的多彩蓝宝石，其中不乏国宝级珍品。如半为黄色半为蓝色的鸳鸯蓝宝石为世界独有，具有极高的文化价值和收藏价值。另外，部分昌乐蓝宝石中含有奇特的包裹体，不少有奇异的活光效应，形成了各式各样的精美图案。如“西天取经”“鱼探龙宫”“一帆风顺”均属世界罕见珍品，价值连城。

经过在郑州生产调度中心排查116位，发现问题用户69位；在小浪底水利枢纽管理区对排查422位，发现问题用户280位。以上均予以解决。

本次对策实施结果将小浪底各用户的IE浏览器支撑组件版本统一为Ver5。升级后的用户浏览器，打开OA系统没有再出现原来的各类奇怪问题和兼容性问题，没有卡顿和等待，用户使用体验得到了提升。

6.2.3 页面动态资源和元素过多

通过前面的活动过程，QC小组成员经过讨论，对此问题设立的目标是：用户访问资讯中心页面时，加载的资源和元素不超过20个。要想达到此目标，需要尽可能减少资讯中心页面的动态化程度。针对此问题，有两种解决方案：

a.将大的动态页面拆分成几个小的页面，同时加载，提高用户端体验。但此方法仍无法免除服务器端重负载问题。

b.将动态页面通过技术手段转换成静态化页面，提供给用户访问。这种方式具有效率极高的特点，且静态化后页面的安全程度有较大提升，是当前IT界广泛采用的方式。

QC小组经过分析研讨，认为最有效的对策是将资讯中心的页面进行静态化处理，让用户访问静态化之后的页面，免除动态资源加载的耗时。2017年12月10日在郑州生产调度中心开始对OA系统资讯中心页面实施逐步静态化处理。至12月26日，该项对策比计划工期提前4天实施完毕。

在实施该对策的过程中，OA项目开发组接到了关于在资讯中心开发公司页面上增设栏目和图像的需求。经过需求分析和小组讨论，QC小组及时将此项对策的目标修改为：用户访问资讯中心页面时，加载的资源和元素不超过30个。

6.2.4 Oracle数据库连接数上限设置不足

通过前面的活动过程，QC小组成员经过讨论，对此问题设立的目标是：将数据库连接数上限值提高至1000。针对此目标，最有效的对策是通过停止数据库实例、修改数据库连接数限制值，将其改动到目标值。

2017年12月12日在郑州生产调度中心办公楼开始调整数据库。至12月15日处理完毕。经过查询，确认已将Oracle数据库连接数上限调整至1000。经Stress Testing工具进行压力测试，并发100～500用户时均能保持稳定的服务状态，队列很快就全部接入连接池。

6.2.5 SQL语句编写、优化不到位

通过前面的活动过程，QC小组成员经过讨论，对此问题设立的目标是：使重新编写的SQL语句执行效率至少提高10倍。针对此目标，最有效的对策是针对小浪底用户业务逻辑和系统实际情况，对SQL语句进行重构和深度优化，重新编写高效率的SQL语句并测试生效。

2017年12月16日开始对SQL进行分析和优化。至12月30日，6条执行时间过长的SQL语句全部优化完毕。对包含这几条SQL语句的页面及功能进行测试后，发现打开前端信息页面和后端公文页面的时间都有较大幅度缩短。

QC小组成员查看该页面对应的有效SQL语句，发现查询耗时和Cost值(查询开销)已降至个位数。此时的效率与优化前相比，已产生5000倍以上的提升，大大超越目标值。

6.2.6 数据表没有建立索引或索引字段不对

通过前面的活动过程，对此问题设立的目标是：使数据表访问速度比目前至少提高20倍。针对此目标，最有效的对策是检查所有数据表，删除无效和错误的表字段索引，重建该表主键与索引并验证。

2018年1月1日开始进行对策实施。至1月10日，所有索引无效或出错的数据表均已处理完毕。

通过对占数据表总数近20%的问题表进行索引重建，这些数据表的查询效率得到极大的提升。QC小组选择其中一张热点数据表进行验证，其Cost值降至个位数，效率和未重建索引前相比提升3000多倍，大大超越目标值。

6.2.7 单一表空间过大

通过前面的活动过程，对原OA系统中迁移来的热点附件表体积过大导致查询效率低下问题而设立的目标是：使针对该表的查询效率至少提高5倍。针对此目标，最有效的对策是新建分区表空间，将原表切割后分块迁移至新表内，再重建分区索引，对表空间进行优化后验证。

2018年1月10日开始进行对策实施。至1月15日，所有过大的数据表均已分区迁移完毕。在对迁移表中最大的10.5GB附件表进行分区重建表空间、优化分区索引等对策实施后，该表的Cost值降低了一半。

但这个结果没有达到本条对策实施的目标要求。QC小组成员通过交流讨论得知，对于体积过大的单一数据表，目前已经做完所有可用的优化操作；若还想使其更快，只能改变数据库本身架构(如采用分布式或内存式数据库等)。这已经脱离了本次OA系统升级改造项目的范畴，无法予以实施。因此，QC小组经过慎重讨论，决定将此对策的目标修改为：使针对该表的查询效率至少提高2倍。

7 效果检查

7.1 活动效果

综合不同时间、不同地点、不同使用环境3种情况，对OA系统响应速度进行了复测统计。统计结果见表3。

表3活动效果复测统计

表3中绿色数值为达标数值。通过此次QC小组活动，已将小浪底OA系统的用户响应速度很好地控制在目标范围以内。本次小组活动目标成功实现。

7.2 社会效益

因为OA系统响应速度的提升，使小浪底用户的办公效率得到极大提升，水利政令和调令的上传下达变得准确、高效，水利公文事务的流转也变得及时、通畅，用户主动办公的意愿得到了较大提升，OA系统也得到了用户的一致好评。

本次活动的成功为其他水利电子政务和水利信息化系统的建设、运维和调整优化提供了切实可行的经验。

8 巩固措施

为了进一步巩固此次活动成果，小组成员根据对策实施结果和小浪底OA系统用户实际情况，制定了以下巩固措施：

a.提高用户终端运维频次和水平。目前已对用户终端的运维频次和方法进行了量化，所形成的指标和要求已写进《小浪底信息化系统用户终端运维规范》中，后续会加强执行。

b.定期对OA系统数据库进行优化。在活动结束后，小组将每年对OA系统数据库进行优化的频次、方式方法等汇总成报告，上报公司领导进行审批，确保数据库能不断以最优的性能状态给程序提供可靠服务。

c.加强对服务器等硬件设备的维护。目前已将对服务器等硬件设备加强巡检和维护的方法和指标写进“日巡检表”“周巡检表”和“月巡检表”等文档，下一步将会加强监督、检查，确保执行落地、到位。