摘要：随着信息化建设的深入和普及，信息系统已经成为了社会的生产、生活重要组成部分，信息系统由各类型复杂的软、硬件组成，功能逻辑结构复杂，数据种类多样，系统的性能犹如系统的生命，是系统正常运行服务的关键，越来越受到人们的重视。如何优化系统性能，是系统设计研发者们必须考虑的问题。性能优化目标只有一个就是提高系统性能，但是性能分析优化的方法策略却多种多样，如系统的架构优化，程序的逻辑优化，内存、I/O、网络、磁盘优化，数据库优化等等。如何选择合适的优化方法，解决性能问题，是系统性能优化的关键。 关键词：性能、优化、系统、升级
System Performance Analysis and Optimization Strategy
Abstract: With the development and popularization of grid informatization, the information systems has become an important part of social production and living. They are composing by types of complex information system software and hardware components. Their functions logical structures are of complex and their data types are diverse. The system performance is like living systems which is the key to the normal operation of the service, attracting more and more people's attention. How to optimize system performance is the problem that must be considered by the designer and developer. Performance Optimization has only one goal that is to improve system performance. However, performance analysis and optimization methods and strategies are various, such as system architecture optimization, logic optimization, memory optimization, I / O optimization, network optimization, disk optimization, database optimization and so on. How to choose a suitable optimization method to solve performance problems is the key to system performance optimization.
Keywords: Performance, Optimization, System, Upgrade
0. 引言
信息系统的性能是一种非功能性要求，虽然不是系统功能关注的重点，但却是反应功能是否正常稳定运行提供服务的关键。如何及时的发现系统性能问题，做到防患于未然是系统建设管理人员必须具备基本能力。本文是总结了多次系统性能优化管理工作中的经验方法，供信息系统的建设管理人员参考。
1. 性能问题表现
系统暴露性能问题，在系统使用过程中通常是非常容易发现的，简单总结起来，主要表现在以下几个方面： 1.1 响应时间
响应时间是指系统对请求做出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。 1.2 延迟时间
虽然软件性能指标本身只涉及软件性能的度量，但考虑到软件性能测试的主要目的是测试和改善所开发软件的性能，对于复杂的网络化的系统而言，简单地用响应时间进行度量就不一定合适了。
考虑一个普通的网站系统。开发该网站系统时，软件开发实际上只集中在服务器端，因为客户端的软件是标准的浏览器。虽然用户看到的响应时间时使用特定客户端计算机上的特
定浏览器浏览该网站的响应时间，但是在讨论软件性能时更关心所开发网站软件本身的“响应时间”。也就是说，可以把用户感受到的响应时间划分为“呈现时间”和“系统响应时间”，前者是指客户端的浏览器在接收到网站数据时呈现页面所需的时间，而后者是指客户端接收到用户请求到客户端接收到服务器发来的数据所需的时间。显然，软件性能测试更关心“系统响应时间”，因为“呈现时间”与客户端计算机和浏览器有关，而与所开发的网站软件没有太大的关系。
如果仔细分析这个例子，还可以把“系统响应时间”进一步分解为“网络传输时间”和“应用延迟时间”，其中前者是指数据（包括请求数据和响应数据）在客户端和服务器端进行传输的时间，而后者是指网站软件实际处理请求所需的时间。类似的，软件性能测试也更关心“应用延迟时间”。实际上，这种分解还可以继续下去，如果该网站系统使用了数据库，我们可以把“数据库延迟时间”分离出来，如果该网站系统使用了中间件，还可以把“中间件延迟时间”也分离出来。
以上的时间分解实际上有两方面的目的。首先，人们通常希望把与所开发软件直接相关的延迟时间和与所开发软件不相关的延迟时间分离开，因为改善前者往往需要开发人员修改程序代码，而改善后者不需要开发人员修改代码，很多时候，开发人员对后者甚至是无能为力的。其次，详细的分解有助于开发人员分析哪些部分是影响软件性能的主要因素，以便于实时性能改善方案。 1.3 吞吐量
吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是T，当有你N个用户使用时，每个用户看到的响应时间通常并不是N*T，而往往比N*T小很多（当然，在某些特殊情况下也可能比N*T大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多步骤难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是
采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。 1.4 并发用户数
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。以网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同时发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。 1.5 资源利用率
资源利用率反映的是在一段时间内资源平均被占用的情况。对于数量为一的资源，资源利用率可以表示为被占用的时间与整段时间的比值；对于数量不为一的资源，资源利用率可以表示为在该段时间内平均被占用的资源数与总资源数的比值。
2. 何时性能优化
系统建设存在这样的一个规律：前期重功能轻性能，后期才会重视性能。建设初期，实现者的注意力只关注系统设计本身的业务功能和系统功能的实现，而忽略系统性能问题。随着系统建设投入应用，系统业务功能、数据量、用户并发量的增加，系统的性能问题逐步暴露，系统性能不断下降，性能问题将会成为系统建设投运过程中的首要问题，此时才重视性能优化，必将话费巨大的代价。所以，系统优化必须在系统设计实现开始时就需要开始重视，系统架构设计，基础平台中间件的选择，代码编写、软硬件配置等就需要考虑系统性能的要求。
3. 性能优化策略
3.1 空间换时间
例如，各种Cache如CPU L1/L2/RAM到硬盘，都是用空间来换时间的策略，这样的策略基本上是把计算的过程一步一步的保存或者缓存下来，这样就不用每次用的时候在计算一遍，比如数据缓存，CDN等。这样的策略还表现为冗余数据，比如数据镜像，负载均衡等。 3.2 时间换空间
少量的空间可能性能会更好，比如网络传输，如果有一些压缩数据的算法，这样的算法比较耗时，但因为瓶颈在网络传输，所以用时间来换空间反而能省时间。
4. 分析优化方法
性能优化主要从操作使用层、业务层、架构层、数据存储、操作系统等几个方面进行分析优化:
操作使用方面，主要考虑操作的简便性、减少系统请求、合理控制分配各个功能点
的使用等方面。
业务层主要考虑业务体系的优化，如对一些流程复杂的业务如何进行流程统一；应
用系统功能如何进行拆分以达到功能配置最优化。
架构层从系统架构和应用架构两个角度考虑，包括事务控制、代码缓存、权限管理
体系、远程调用、工作流引擎等内容。其优化手段主要有优化缓存管理、支持多数据源、应用服务部署优化等方面。
数据库层的优化范围包括数据库的库表结构设计、数据存储、数据库操作等方面考
虑，主要优化手段包括表结构设计的规范化、分区存储、查询优化、索引的使用等策略。
操作系统层的内容考虑系统的并发用户数、吞吐量，系统可靠性等方面，优化手段
包括多任务处理、负载均衡等手段。
4.1 系统架构
优化应该按照从大到小的原则进行，这样的顺序便于从整理发现解决制约系统性能的关键问题，集中精力解决。优化性能，首先需要从系统结构或者框架入手，思考设计最佳的性能结果或框架，最后到编程工具、控件的选择，及SQL语句优化之类的细节问题。比如C/S、B/S混合结构的使用，C/S结构可以现实数据的快速传递和安全存储，但是在易推广远程应用
发面却不足；B/S结构的系统易与集成和扩展，可提提供远程的数据服务于管理，但在数据的交互性、动态服务和突变显示方面比较欠缺。因此，针对系统中的不同功能，选择合适的结构来实现。 4.2 代码逻辑
精简代码：代码越精简，执行效率越高，特别对于C#、Java等面向对象语言，由于面向对象的设计，多一行代码，执行时将会多增加一系列的关联对象的加载和执行，所以代码越精简性能就越高。代码精简的水平取决于编程人员水平的高低，但是有一些代码优化策略，只要编码过程中注意应用，可以起到提高性能的目的，如：减少循环的层数，减少递归，在循环中少申明变量，循环的执行SQL语句查询，少做分配和释放内存的操作，尽量的把循环体内的表达式抽取到循环外，条件表达式尽量的将最多状态放置在前面的判断中，合理的使用异常机制等等。
并行处理：多核的CPU配置已经是常见的配置，程序设计中如果能够充分的考虑多进程多线程的执行，将非常有利于充分的利用计算资源，通过空间换取时间，达到提高性能的目的。
4.3 网络通信
信息系统一般部署在成熟具有一定规模和覆盖面的网络通信设施的基础之上，网络的结构、带宽等均已经固定，短时间内不会有大的升级改进。网络通信的优化，通常在系统架构部署，数据压缩，使用数据库存储过程等方面进行优化改进，旨在减少网络数据传输量，从而达到提高网络性能的目的。 1) 系统架构部署
对于网络系统而言，网络架构的部署模式，决定着系统性能的优劣，如地图空间数据服务，卫星影像、数据地图数据量巨大，需要大量的网络带宽容量，如果采用分布式部署模式，能够有效减少集中部署，将数据分布于最接近于应用终端的局域网络中，能够有效的减少系统对主体网络的压力，提高系统整体性能。 2) 数据压缩
数据压缩是有效的时间换空间方法，利用高效的压缩算法，将零散的数据或者数据文件惊醒打包压缩，利用服务端或客户端的计算资源，减少网络数据传输的容量，从而提高网络传输效率。
3) 数据库存储过程
如果数据库服务器和应用服务器之间不能部署在同一局域网络之中，应用服务需要请求大量的数据进行运算，那么在数据库服务器计算资源充分的情况，可以考虑利用数据库存储过程，执行部分的统计，数据归档等计算过程，仅将结果提供给应用服务器，该方式也能有效的减少网络传输资源的消耗，提高网络性能。 4.4 数据缓存
缓存是好东西，基本上90%的系统架构优化都是在围绕着如何利用好缓存。缓存真是无处不在，硬件上看，有硬盘缓存，RAID卡缓存，存储缓存，主存，NUMA特性，CPU L3-L2-L1等等。软件架构上看，有全局数据缓存，私有数据缓存，连接池，应用服务器缓存，WEB服务器缓存，CDN缓存，客户端文件缓存，客户端内存缓存等等。基本上大型系统都会有多级缓存，否则需要非常高的硬件投入才能解决问题。硬件缓存通常都比较智能，或者说99%的情况下我们不需要修改配置，即使修改带来的性能提升一般也不会太多，除非你的软件有较明显的缺陷，你对硬件和你的软件特性已经了解得非常深入。软件缓存架构带来性能的提高，往往也带来了负面的问题，如架构复杂化，数据同步多，数据实时性差，维护成本高，系统调试复杂等问题，所以对于软件架构上任何一个缓存架构，都需要深入分析是否有必要。我认为如果增加一层缓存架构，至少要有5倍以上的提高提升，否则就要分析成本了。对于中小型系统，不建议有复杂的缓存架构，因为让系统能更快速发展比提供更好的性能更有意义，杂的缓存架构往往需要投入更多的人力成本。 4.5 SQL语句 1) 并行处理
并行SQL使得SQL语句可以被多线程或进程同时处理。当前，多核处理器的广泛应用，意味着运行Oracle数据库的即便是最廉价的现代计算机也会包含一个以上的CPU。数据库服务系统通常会跨多个独立磁盘设备分布保存数据库文件。 没有并行技术的时候，也就是SQL语句被顺序处理，一个会话只能利用这些CPU或者磁盘设备其中之一。结果，串行执行SQL语句不能利用整个计算机的处理能力。并行执行使得单个会话和SQL语句能利用多个CPU和磁盘设备的处理能力。 并行处理可以把合适的SQL语句的性能提升到一定程度，这种提升程度通常是其它任何方法都做不到的。
2) 高效SQL
关于SQL语句的优化，首先也是要使用工具，比如：MySQL SQL Query Analyzer，Oracle SQL Performance Analyzer，或是微软SQL Query Analyzer，基本上来说，所有的RMDB都会有这样的工具，来让你查看你的应用中的SQL的性能问题。 还可以使用explain来看看SQL语句最终Execution Plan会是什么样的。
还有一点很重要，数据库的各种操作需要大量的内存，所以服务器的内存要够，优其应对那些多表查询的SQL语句，那是相当的耗内存。 4.6 数据库 1) 数据库诊断报告
通常数据库工具都会集成自身的性能诊断分析工具，收集统计数据库运行的状况，通过分析诊断报告，可以明确数据库优化的内容。 2) 数据库参数
数据库的相关参数，在系统运行中起到关键的作用，合理的设置，能够充分的发挥数据库服务器的计算资源利用率，充分提高的数据库的性能。 3) 表空间
根据业务模块的数据读写频率，或者磁盘本身的读写效率，合理的分配表空间，将读写频繁的数据分别置于不同磁盘，提高表空间的利用率，从而整体提高数据读写的效率，均衡磁盘读写的压力。如：常用的表空间利用率优化方法有：数据与索引表空间分离、同一表空间文件分置在不同磁盘、对象型数据存储独立表空间等等。 a) 建立分区表
按照数据库的设计原理，当一个数据表的数据量非常大时（通常超过千万级别），通过建立分区表，可以有效提高数据读写的效率，降低死锁情况的发生。 b) 碎片整理
作为影响数据库性能的一大因素——数据库碎片，应当引起DBA的足够重视，及时发现并整理碎片乃是DBA一项基本维护优化的内容。 c) 范式设计
在设计关系数据库时，应该让数据表尽量的符合第三范式等级，以便最大限度地提高数据的一致性，减少数据冗余和不规则的更新，这是数据库设计的常识。第三范式的数据库操作往往比第一范式、第二范式需要更多的表连接，会非常消耗CPU和磁盘IO资源，从而降低
系统性能。其实，合理的引入非规范化设计，反而会简化查询，改善系统的性能。非规范化的过程可以根据性能方面的不同，采用不同的方法进行，从实践经验可以利用下面的方法提高性能：
规范化设计产生了四路或者更多路的合并关系，可以考虑数据实体中加入重复属性。 常用的计算字段（如合计、最大、最小值）可以考虑直接存储到数据库实体中，减
少每次计算带来的资源消耗。 重新定义实体以减少行列数据的消耗。 4) 索引
a) 建立索引常用的规则
表的主键、外键必须有索引；
数据量超过300条或者多个数据块的表应该有索引； 经常与其他表进行连接的表，在连接字段上应该建立索引；
经常出现在Where子句中的字段，特别是大表的字段，应该建立索引； 索引应该建在选择性高的字段上；
索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引； 复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替： 正确选择复合索引中的主列字段，一般是选择性较好的字段；
复合索引的几个字段是否经常同时以AND方式出现在Where子句中？单字段查询
是否极少甚至没有？如果是，则可以建立复合索引；否则考虑单字段索引； 如果复合索引中包含的字段经常单独出现在Where子句中，则分解为多个单字段索
引；
如果复合索引所包含的字段超过3个，那么仔细考虑其必要性，考虑减少复合的字
段；
如果既有单字段索引，又有这几个字段上的复合索引，一般可以删除复合索引； 频繁进行数据操作的表，不要建立太多的索引； 删除无用的索引，避免对执行计划造成负面影响；
以上是一些普遍的建立索引时的判断依据。索引的建立必须慎重，对每个索引的必要性都应该经过仔细分析，要有建立的依据。因为太多的索引与不充分、不正确的索引对性能都毫无益处：在表上建立的每个索引都会增加存储开销，索引对于插入、删除、更新操作也会
增加处理上的开销。另外，过多的复合索引，在有单字段索引的情况下，一般都是没有存在价值的；相反，还会降低数据增加删除时的性能，特别是对频繁更新的表来说，负面影响更大。
b) 创建索引的注意事项
在创建Oracle索引时，有一些问题使我们需要注意的，下面介绍创建Oracle索引的一些注意事项，希望对您学习创建Oracle索引方面能有所帮助。
1、一般来说，不需要为比较小的表创建索引；
2、即使是大表，如果经常需要查询的数据不超过10%到15%的话，那就没有必要为其建立索引的必要。因为此时建立索引的开销可能要比性能的改善大的多。这个比例只是一个经验的数据。如果数据库管理员需要得出一个比较精确的结论，那么就需要进行测试分析。
3、如对于一些重复内容比较少的列，特别是对于那些定义了唯一约束的列。在这些列上建立索引，往往可以起到非常不错的效果。如对于一些Null值的列与非Null值的列混合情况下，如果用户需要经常查询所有的非Null值记录的列，则最好为其设置索引。如果经常需要多表连接查询，在用与连接的列上设置索引可以达到事半功倍的效果。
4、数据库管理员，需要隔一段时间，如一年，对数据库的索引进行优化。该去掉的去掉，该调整的调整，以提高数据库的性能。
5、通常来说，表的索引越多，其查询的速度也就越快。但是，表的更新速度则会降低。这主要是因为表的更新(如往表中插入一条记录)速度，反而随着索引的增加而增加。这主要是因为，在更新记录的同时需要更新相关的索引信息。为此，到底在表中创建多少索引合适，就需要在这个更新速度与查询速度之间取得一个均衡点。
6、对于一些数据仓库或者决策型数据库系统，其主要用来进行查询。相关的记录往往是在数据库初始化的时候倒入。此时，设置的索引多一点，可以提高数据库的查询性能。同时因为记录不怎么更新，所以索引比较多的情况下，也不会影响到更新的速度。即使在起初的时候需要导入大量的数据，此时也可以先将索引禁用掉。等到数据导入完毕后，再启用索引。可以通过这种方式来减少索引对数据更新的影响。相反，如果那些表中经常需要更新记录，如一些事务型的应用系统，数据更新操作是家常便饭的事情。此时如果在一张表中建立过多的索引，则会影响到更新的速度。
4.7 硬件
在IT人的眼里硬件的费用是很高的，软件成本是很低的甚至可以忽略，因为硬件需要购买，基本上没有免费的硬件，而软件可以选择开源免费的，或者自己开发。因此在遇到性能问题是程序员首先想到的优化软件性能。但在这个人工成本上升，硬件成本下降，硬件性能或容量随摩尔定率的发展的时代，我们也应该重视硬件的优化方法。
通过硬件升级可以快速解决系统性能问题，对于可预估的系统容量性价很好。但顶配或者新出来的硬件贵得离谱，最新的硬件往往也会存在一些未知的BUG，所以硬件升级一般不会选择1年内出来的全新架构的设备，而通常选择2年以上比较成熟的硬件性价比会更好。但是硬件升级往往会有上限，顶配或者最高性能的硬件往往性价比不好，所以在硬件升级解决问题后同时需要分析业务增长导致更多硬件成本的问题。选择软件优化还是硬件优化是一种技术成本平衡决策，有时软件也需要针对硬件做特定的优化。
5. 测试验证
性能测试属于软件测试的范畴，是软件系统级别的测试，其目的是验证用户的性能需求是否满足要求。它不仅是用测试工具去运行一些测试脚本，证明系统是否满足性能指标。更关键的是要识别系统瓶颈和产生瓶颈的原因，辅助优化调整平台设置来达到最佳的性能。
性能测试主要包括负载测试和压力测试两个方面。负载测试时最常见的验证一般性需求而进行的性能测试，主要是考察系统软件在既定的负载下的性能表现，一般体现为响应时间、资源利用率、并发用户数等指标。压力测试是为了测试系统在极端情况下的表现，如超负荷的交易量和大用户数并发，简单的说，压力测试的预期目的就是发现系统问题，找到系统正常运行的临界值。一般体现为最大并发用户数，最大吞吐量等。
如LoadRunner等是常用的性能测试软件，通过模拟真实的用户行为，通过负载、并发和性能实时监控以及完成后的测试报告，分析系统可能存在的瓶颈，有效的手段之是并发控制，通过在控制台的设置，以达到同一个业务同时模拟成千上万的用户进行操作。
在利用软件测试条件不具备的情况，同样可以采用手动的方式，通过选取优化检测的场景，对比优化前后的性能变化量，如，响应时间、等待时间、并发用户数等，来进一步发现和分析性能问题，确认性能优化的效果。
6. 总结
性能与应用系统的代码、应用服务器都有着密切的关系。应用的代码设计的再好，如果应用服务器的配置不当，性能也不会好；同样地，应用服务器调整得再好，也难以掩盖应用代码中存在的缺陷。因此，首先要保证应用有一个稳固可靠的体系结构，有最优质高效的代码，在此基础上再来集中精力调整应用服务器，这样才能达到大集中应用系统性能优化的理想效果。本文仅是项目工作中性能优化技术经验的一些整理总结，难免不足，欢迎大家讨论改进。
参考文献
[0] 骆涛. 面向大数据处理的并行计算模型及性能优化[D]. 中国科学技术大学 2015 [1] 袁爱梅. Oracle数据库性能优化研究[D]. 华东师范大学 2007 [2] 谭建平. Web网站系统性能优化研究及其应用[D]. 重庆大学 2007
[3] 孙风栋,闫海珍.Oracle 10g数据库系统性能优化与调整[J]. 计算机技术与发展.
2009(02)
[4] 宋秀荣.Oracle数据库性能优化及实时监控研究[D]. 燕山大学 2009
因篇幅问题不能全部显示，请点此查看更多更全内容