《性能优化技术在WEB应用系统中的探讨》-工学论文，通信论文-论文范文参考-科学狗论文网

标题

性能优化技术在WEB应用系统中的探讨

范文

郑林芳

【摘要】 WEB应用系统目前作为信息化建设的主要模式，在各行各业得到广泛应用。某市存量房网签交易系统是服务于市民的二手房网上合同签订的交易平台。通过对网签平台的硬件层面、应用部署层面、数据库层面和应用系统层面对系统的性能瓶颈进行了分析，通过集群应用服务器、负载均衡、ORACLE预编译等技术对系统进行性能优化，改善系统性能，以满足系统全面应用的性能要求。

【关键词】性能优化数据库 SQL

本人在企业实践过程中，有幸参于了某市存量房网签交易系统性能优化的工作。WEB应用系统目前作为政府信息化建设的主要工作模式，在国内各工作场合都得到广泛的应用。作为服务于市民的二手房网上签订合同的服务平台，系统通过产权即时验证、网签即时锁定、二手交易资金监管等手段，对市民之间的二手房买卖进行监督管理，有效地保障了市民的权益。系统推广应用到全市后，渐渐出现了系统性能下降，请求超时等一些问题，因此对关系民生的网签系统进行性能优化的工作迫在眉睫。

该存量房网签系统采用JAVA的WEB应用技术开发，应用服务器和核心数据库分别采用 WEBLOGIC10.0和ORACLE10G。

通过用户反馈情况，高峰时期到现场对系统应用的前台体验以及详细的调研情况，项目组深入分析系统了系统硬件层面、应用系统层面、数据库层面可能存在性能瓶颈问题，最终从以下方面对此应用平台进行了优化。

一、硬件服务器及应用部署层面的优化

WEB应用在服务器及应用部署层面上的性能优化，首先是确认服务器配置是否能承当得起应用的性能要求，是否需要进行更换升级。但同时必须考虑到，虽更换服务器短期内能解决部分问题，但是随着时间的推移，问题可能还会继续出现，仍需要深入分析服务器及应用部署可能存在的瓶颈和出现系统不稳定的潜在因素，因而从WEB服务器、数据库服务器和网络环境等方面进行详细分析和探讨：

1.1 WEB服务器的优化

WEB服务器主要以事务处理为主，需提供不间断的服务，对可靠性的要求较高，故需要高性能的CPU处理和内存缓存能力，但对磁盘的性能要求不高。目前保障服务的可靠性，可对应用级和主机级采用多点冗余，同时提供对外服务的方式来保证系统平台的可用性。在配置应用服务器时还应考虑应用的架构，对于采用.NET开发的系统，必须配置运行于WINDOWS SERVER服务器上，而对于使用JAVA框架开发的业务系统，建议配置UNIX或者LINUX作为应用服务器的操作系统，使稳定性达到最优。

针对存量房网签系统，在服务器上做了以下优化：

第一：原系统采用JAVA技术开发，为了使应用效果达到最佳，调配了两台性能较强的SUN小型机作为应用服务器。

第二：对提供对外服务的WEB应用来说，每个服务配备过多内存并不能使内存处理能力达到最优，在实际应用测试中发现内存设置为4G时系统运行效率比较理想。根据两台服务器都配备有64G内存的现状，项目组利用WEBLOGIC CLUSTER技术在每台机器上部署8个相同的对外服务，使每个对外服务都配置4G内存，由WEBLOGIC ADMIN服务器统一管理两台服务器。同时对外服务时可达到16个对外服务端口，大大增加了处理能力，而且多线程的对外服务也大大增加了系统的可维护性，可对各线程分别进行更新维护。

第三：在实际应用中，对外WEB应用的优化还可以与云技术相结合。对多台应用服务器进行虚拟化，根据需要虚拟主机，再将虚拟主机配备给不同的系统，达到服务器资源共享功用，减少主机配备的浪费，在本次优化中由于应用服务器为专用服务器并未使用虚拟化技术。

最后：为使对节点服务得到更有效配置，还通过硬件负载均衡将收到的服务请求用负载均衡设备进行转发，本优化项目中采用了F5链路负载均衡设备来实现，比利用APACHE实现的软件负载均衡更为有效。

在WEB服务器硬件设备进行调优后，系统平台仅在电路检修、大型系统补丁上线等情况下才暂停对外服务外，其余时间都能正常可靠提供服务，没有出现系统崩溃宕机等情况。整体优化后平台结构如图1所示，在应用服务器和应用部署层面实现了多点冗余、负载均衡。

1.2数据库服务器方面的优化

数据库在系统中的应用越来越广，其存储的数据量也越来越大，存量房网签系统其数据存储量达到500G。网签系统在提供服务时，很大一部分时间是耗费在数据库操作方面，故数据库的优化工作至关重要。数据库服务器的主要任务是处理大量的数据操作，其中最影响系统性能的其中一个因素是磁盘的I/O读写速度，要解决好这个问题先要对磁盘进行硬件优化处理。

第一：采用磁盘阵列，把数据库系统的磁盘进行条带化处理，让磁盘读写操作分布在RAID5的不同的磁盘中，减少集中读写单个磁盘的现象，从而增强I/O处理能力。

第二：为了增加可靠性，采用ORACLE RAC双机负载均衡系统，提供强而有力的数据库保障。

第三：在预算充分的情况下，采购配置固态硬盘，提高硬盘的读写速度。

为了保持系统的可用性，项目使用了两台数据服务器并配置为ORACLE RAC双机负载，同时为了兼顾经济性，采用了固态硬盘和普通磁盘混搭的方式来部署存储，将附件、大字段等容量大但读写频率较少的数据表存储在普通磁盘上，而把经常进行读写和查询操作的多记录数据表存储于固态硬盘之中，以达到优化数据库对外服务的效率。

项目采用数据库负载均衡后，应用配置采用图2的方式实现数据库连接，以达到双机负载均衡的效果。

1.3网络带宽方面的优化

基于Web的存量房网签系统对外提供的服务性能高低还与网络的带宽有直接的影响。系统优化前，服务只提供100M带宽，为了提高服务性能，优化方案里采用了1000M的对外服务光纤，对网络进行升级处理。

二、数据库应用程序层面的优化

由于优化时存量房网签平台已投入使用了较长一段时间，业务逻辑已基本符合业务要求，所以此次性能优化，没有将精力放在业务流程的优化上，而是放在硬件和数据库的优化方面，因为数据库的访问速度直接影响着交易平台的性能。数据库硬件方面的优化上文中已进行讨论，现将从数据库应用程序方面来探讨一下系统平台的数据库优化方案。

数据库在应用程序优化通常可分为两个方面：SQL语句和源代码。对于源代码，因涉及到对程序逻辑的改变，时间成本和风险上代价很高，并且对数据库系统性能的提升收效有限；所以系统平台在数据库应用程序方面的优化主要以优化SQL语句为主。其原因有：第一：SQL语句消耗了70%至90%的数据库资源；第二：SQL语句是对数据库进行操作的惟一途径，对数据库系统的性能起着决定性的作用；第三：SQL语句独立于程序设计逻辑，对SQL语句进行优化不会影响程序逻辑；第四：不同的SQL语句写法有不同的性能，且差异非常大。

项目组在对平台系统全面扫描分析过程中，发现数据库并没有处于最优水平。其问题主要集中在以下方面：

第一：系统数据库部分频繁调用的数据库操作语句，未采用CACHE技术，未充分利用ORACLE的预编译技术，使频繁使用的语句仅因为个别参数不同而被数据库服务器频繁编译，耗费大量的CPU工作时间。

第二：数据统计工作直接基于业务库进行操作，在统计工作周期内数据读取争取资源严重。通过数据库检测，在统计周期内由于统计工作进行大量的数据读取运算，使数据库的读写性能严重降低，有时甚至影响到应用对外提供服务。

第三：由于产权认证的产权信息分别部署在各区分局，且各区分局的数据环境和数据基础不统一，使整体性能得不到保证。

针对以上情况，使在不改变整体业务逻辑的情况，项目组在数据库应用层面采取了多项措施来提高了系统平台性能。

1、优化WEBLOGIC的数据连接配置。

在实际应用中数据库连接配置过大将导致资源浪费，过低即导致资源的频繁申请，影响效率，项目组根据WEBLOGIC的JDBC连接池机制来管理，将JDBC连接缓冲池设置为“常用均值+常用均值*50%”，分析得到常用均值设置为20个左右，即JDBC连接缓冲池个数设置为30个，同时将最大值设置为50，超出设置值后允许每次增加10个，这样既保证了系统正常使用，同时运用连接池机制，将提高系统的效率。

2、查询操作在各种数据库操作中所占比重较大，而查询操作所基于的SELECT语句在SQL语句中是代价最大的语句。

因此优质的SQL语句和高效的查询优化技术，可以帮助提高应用系统的性能。在优化工作中检查SQL语句，对SELECT查询语句，尽量避免使用SELECT *的操作，字段提取按照“需要多少，提取多少”的原则，查询结果应返回给应用程序所需要的最少数量的行和列；如果系统确实需要每一列，最好在SQL语句中显式呈现每一列名称，这样可以避免了服务器替换*所花费的时间，因为这个工作是通过查询数据字典完成的。

3、采取逐步优化的方式对可以采取预编译的数据库操作语句，引入预编译技术，提高CACHE的命中率。

在充分利用数据库的预编译技术下，对重复使用的数据库语句使用变量注入的方式，减少SQL语句不必要的编译，如“select A from t1 where L1=3”和“select A from t1 where L1=4”这类查询语句，在数据库中被认为是两个不同语法的语句，会被重复编译，如采用“select A from t1 where L1=X”，通过X的赋值来得查询结果，数据库系统仅会对第一次调用进行预编译，后续的语句将不再做编译，从而提高了数据库的处理效率。

4、对于目前不便修改（多为对系统框架修改较大）的SQL语句进行登记造册，作为下次系统进一步优化或升级的建议进行记录。

5、对统计工作进行分类，在优化统计逻辑的同时，对时效性要求不是很高的统计工作，建立专用于统计的物化视图。通过网络业务不繁忙时段的同步，为统计工作提供物化视图，以有效减少了同时工作对业务产生影响

三、应用系统层面的优化

项目在应用系统层面上优化主要考虑以下两方面：

第一：将系统的页面处理和事务处理分离，对事务进行封装，部署时采用APACHE处理静态页面，WEBLOGIC处理业务逻辑的技术，使页面处理和事务处理分离。

第二：对各区的数据认证充分利用ORACLE的数据同步技术，将原来的产权一次认证方式调整为二次认证的方式进行数据认证。产权认证数据库每天晚上从各区的数据库中同步产权数据，市民在签约时采用同步数据库的数据进行第一次产权认证，由于采用了已集中的产权数据，数据库索引齐备、数据库部署在应用服务器的同网段，使整个签约操作受数据库性能影响降到最低。在市民间签约提交时应用服务器提请第二次产权认证，第二次认证虽需读取分局数据，但只需查证当天是否发生过数据改变即可，数据发生改变的认证不通过，数据无改变的验证有效。此项应用层面的优化措施有效提高了应用服务器与数据库服务器的交互效率，从而提高了系统性能。

但是在最终实施中由于考虑到存量房网签系统单纯的静态页面不多，并且测试发现使用APACHE不能实质性提高系统性能，所有没有实施。反而将业务逻辑调整为二次验证后，利用数据集中的优势，提升应用性能，提高市民的现场应用满意度。

四、总结

在本次项目优化中，通过以上措施的逐步实施，使存量房网签系统数据库服务器的负荷得到有效的减负，且没有因为应用的全面推广而出现超负荷宕机的现象发生；结合应用服务器的重新部署，服务器的响应速度明显加快，基本实现了服务操作3秒内响应的优化目标，服务器整体性能运行正常，在近段时间市民购房热潮中能沉稳应对，达到预期效果。

但是在本次优化中，仍有部分问题尚未解决，首先是部分频繁调用的SQL语句由于对系统修改较大未能优化，加大了数据库编译压力；

再次对关系民生的产权数据未能全面集中认证，设计二次认证也只不过是一个权宜之计，分布式存储无法对实时的认证提供有效的、准确的认证，下一步数据迁移工作将会是一项重点；

第三，因为系统已试运行一年，基本业务逻辑已确定，业务逻辑的优化变更可能会导致系统出现其他错误，因此本次优化过程中，并没有对业务逻辑做优化工作，只能将此工作留至下一次系统升级。

参考文献

[1] 王新根. Web后端性能优化关键技术研究[D]. 杭州：浙江大学.2012：15-25.

[2] 岑巍.数据库优化在海量数据下的研究与应用[J].计算机时代.2015（2）：33-35.

[3] 王晓东.浅谈计算机性能优化技术中的问题及对策[J].计算机光盘与软件应用.2014（3）：311-312

[4] 谢书良.C#任务导引教程[M].北京：清华大学出版社.2012

随便看

科学优质学术资源、百科知识分享平台，免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。