LR-系统性能调优
12LoadRunner
自动化性能测试原理
首先保证一个用户能正常访问，记录访问过程，记录 通讯包
通过测试工具模拟更多用户同时发通讯包，后台无法 区分是人or工具
通过测试工具模拟大量用户同时向后台发出请求，来 达到产生压力和指定压力的目的，在产生指定压力的 同时监控后台系统的资源消耗情况，监控客户端的请 求处理时间
熟悉软件测试的基本理论 熟悉一门编程语言 熟悉SQL 熟悉WEB服务器 熟悉网络协议，比如HTTP，TCP/IP 掌握测试理论 熟悉一个性能测试工具
性能测试的流程 制定性能测试目标
选择性能测试工具 设计性能测试 监控分析系统 性能调用
手工性能测试
要考虑的问题: 1.资源：多台测试机，多个测试人员 2.协调：有一个“总司令”，用于协调测试人员 3.重复：需要多轮测试，手工会带来误差 4.分析：“总司令”需要分析结果数据是否达到要求，
Loadrunner9.5安装
2.Loadrunner安装警告信息，选择否，忽略警告提 示：
Loadrunner9.5安装
3.若系统未安装以下程序，单击“确定”后，程序会联网进行下载并安 装：
Loadrunner9.5安装 4.Loadrunner所需功能模块进行联网下载：
Loadrunner9.5安装 5.安装后重新启动计算机：
识别系统中的弱点。受控的负荷可以被增加到一 个极端的水平并突破它，从而修复系统的瓶颈或 薄弱的地方。
系统调优。重复运行测试，验证调整系统的活动 得到了预期的结果，从而改进性能，检测软件中 的问题。
性能测试方法
性能测试的基准大体有以下几方面：
响应时间 从应用系统发出请求开始，到客户端接收到最后一个字节数据为止所消耗 的时间。合理的响应时间取决于实际的用户需求。
性能测试基本理解
性能测试基本理解性能测试基本了解什么是性能测试通过模拟⽣产环境运⾏的业务压⼒量和使⽤场景组合，测试系统的性能是否满⾜⽣产性能要求。
性能测试应⽤的四个领域1. 能⼒验证：关注在给定的软硬件条件下，系统能否具有预期的能⼒表现，例如，在要求平均响应时间⼩于2秒的前提下，如何判断系统是否能够⽀持50万⽤户/天的访问量？2. 规划能⼒：关注如何使系统具有我们要求的性能能⼒，例如，某某系统计划在⼀年内获客量在到xxx万，系统到时候是否能⽀持这么多⽤户量？如果不能需要如何调整系统的配置？3. 性能调优：主要⽤于对系统性能进⾏调优，例如，某某系统上线运⾏⼀段时间后响应速度越来越慢，此时应该如何办？4. 缺陷发现：发现缺陷或问题重现、定位⼿段，例如，某些缺陷只有在⾼负载的情况下才能暴露出来，如线程锁、资源竞争或内存泄露。
性能测试类型我们在做性能测试的时候⼀般都是笼统的称为性能测试，其实性能测试分为多个类型：负载测试，压⼒测试，性能测试，基准测试，并发测试，配置测试，稳定性测试，失效恢复测试。
下⾯就详细说说这些名词之间的区别和特点。
负载测试负载测试是对被测系统不断增加压⼒（即⽤户并发数），直⾄性能指标超过预期或者某项资源使⽤达到饱和状态（就是加压到系统崩溃）。
重点观察系统正常运⾏的最⼤值时候的⼀些数据和资源使⽤。
观察程序、⽹络、服务器、还是数据库等哪个⽅⾯存在瓶颈。
⽬的：发现系统处理能⼒的极限。
找出问题所在，做这个就是为了发现系统是否还有隐藏的能⼒。
⽤来改进调优。
压⼒测试压⼒测试是系统在⼀定饱和状态下，例如cpu、内存、磁盘I/O在饱和使⽤情况下，系统能够处理能⼒，以及系统是否会出现错误。
（可以参考负载测试情况）⽬的：该⽅法通过增加压⼒，使系统资源使⽤保持在较⾼的压⼒下，检验此时应⽤的表现，重点在于有误出错信息产⽣，系统对应⽤的响应时间等。
性能测试性能测试⼀般是根据模拟⽣产运⾏的业务压⼒量和使⽤场景组合，测试系统的性能是否满⾜⽣产性能要求。
PICC承保系统性能测试方案_IBM
PICC承保系统性能测试方案东南融通（中国）系统工程有限公司2010年06月本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属东南融通（中国）系统工程有限公司所有，受到有关产权及版权法保护。
任何个人、机构未经东南融通（中国）系统工程有限公司的书面授权许可，不得以任何方式复制或引用本文件的任何片断。
目录1.引言 (5)1.1.编写目的 (5)1.2.预期读者 (5)1.3.术语定义 (6)2.测试范围 (7)2.1.测试目标 (7)2.2.业务模型 (8)3.测试启动/结束/暂停/再启动准则 (9)3.1.测试启动准则 (9)3.2.结束准则 (9)3.3.暂停/再启动准则 (9)3.4.局限性 (10)4.测试方法 (11)4.1.需求分析阶段 (11)4.2.数据准备 (11)4.3.脚本录制阶段 (11)4.4.场景设计阶段 (11)4.4.1基准测试 (11)4.4.2单交易负载测试 (12)4.5.场景执行阶段 (12)4.6.系统监控方案 (12)4.6.1监控目的 (12)4.6.2监控方法 (13)4.6.3服务器资源监控方案 (13)4.6.4应用监控方案 (14)4.6.5数据库监控方案 (15)4.6.6 Loadrunner监控方案 (15)4.7.分析阶段 (16)4.8.总结阶段 (16)4.9.测试工具 (16)5.测试环境 (17)5.1.系统架构图 (17)5.2.测试环境机器配置表 (18)6.测试计划 (19)7.测试交付工作产品 (20)8.测试风险分析 (21)9.性能测试案例设计 (23)9.1.投保单录入_1 (23)9.2.投保单录入_2 (24)9.3.投保单录入_3 (25)9.4.投保单录入_4 (26)9.5.续保 (29)9.6.投保单查询 (30)9.7.系统登录 (30)10.测试场景设计 (32)10.1.投保单录入 (32)10.2.续保 (32)10.3.投保单查询 (32)10.4.系统登录 (33)1.1.编写目的本文档是对PICC承保系统性能测试所做的方案，本次性能测试实施方案有助于实现以下目标：明确性能测试需求、范围、策略；明确性能测试的目标、内容、方法、环境、进度和标准；明确性能测试的工作产品；该方案是实施本次性能测试的指导性文档。
MySQL调优参数配置
MySQL调优参数配置MySQL服务器硬件优化硬盘：mysql 对磁盘的要求⽐较⾼，包括随机读写的带宽和IOPS和顺序读写的带宽和IOPS，可以通过使⽤⾼转速磁盘、商业FC存储、固态硬盘等⽅式提⾼IOPS及读写带宽；内存：mysql 服务器内存越⾼，可加载的热点索引数据越多，可提供给操作线程的内存越多。
Mysql 读写操作越快；CPU： mysql正常的查询对CPU要求⽐较低，如果磁盘和内存不⾜CPU配置过⾼更容易引起磁盘吞吐量下降严重导致性能过低，所以硬件优化⾸先优化硬盘和内存，只有硬盘和内存⽆瓶颈后增加CPU才会使mysql性能更⾼如果有⼤量的慢查询则很容易将CPU跑满，所以CPU如果过⾼应⾸先检查慢查询优化慢查询，如慢查询优化完成应⾸先检查是否由于磁盘IO过⾼引起的CPU过⾼。
内存优化-数据索引页共享内存innodb_buffer_pool_size1. 作⽤：pool-size可以缓存索引和⾏数据，值越⼤，IO读写就越少，如果单纯的做数据库服务，该参数可以设置到电脑物理内存的75-80%2. 调优参考计算⽅法：val = Innodb_buffer_pool_pages_data / Innodb_buffer_pool_pages_total * 100%val > 95% 则考虑增⼤ innodb_buffer_pool_size，建议使⽤物理内存的75%val < 95% 则考虑减⼩ innodb_buffer_pool_size，建议设置为：Innodb_buffer_pool_pages_data * Innodb_page_size *1.05 / (102410241024)innodb_buffer_pool_instances1. 作⽤：innodb_buffer_pool_instances的值主要⽤于将innodb buffer pool进⾏划分，通过划分innodbbuffer pool为多个实例，可以提⾼并发能⼒，并且减少了不同线程读写造成的缓冲页。
基于Xen的X86虚拟机性能调优
Ｖ ｘ 发生控制、Ｖ ｘ 原因等信息。 ＭＥ ｉ ｔ ＭＥ ｉ ｔ
虚拟机管理器 （ ＭＭ） Ｖ
在 图 ２所示 的方案 中，Ｖ ＭＭ 运作在根环境 的 ｒ ｇ 。作 ｉＯ ｎ 为Ｘｎ ｅ 的一个特色 ，根环境中还有 一个 比较特殊 的管理虚拟 机 Ｄｏ ｉ 。它的内核是修改过的 Ｌｎ ｘ称为 Ｘｅ０ ，通 过 ｍａｎ ０ ｉｕ （ ｎ） Ｖ ＭＭ 提 供的 Ｈｙ ｅｃｌ跟 ＶＭＭ 协同完成管理工作 。它的用 ｐ ｒａ ｌ
Ｉ ｙｗ ｒｓ ｅ ＴｘＥ ｅｔｃ； ｉｕｌ ａｈｎｓ Ｋｅ ｏｄ｜Ｘ ｎ －； ｘｎａｅＶｒ ａｍ ｃｉ Ｖ ｒ ｔ ｅ
１氍述
从 ＩＭ在其 ￥６ 大型机上第 １ Ｂ ３０ 次实现虚拟机模型算起 ，
控能力，而且充分考虑了如何有效减小虚拟机的开销。结合 Ｘｎ ｅ 高性能、开源的优点和 Ｖ － Ｔｘ的优良特性和基于 Ｘ ｎ的 ｅ Ｘ ６纯虚拟机解决方案，本文提出了一个在其基础上的性能 ８
ｉ ￣ｔ ｔ Ｎ ｗｔ ｒ ａ ｗ ｅ ｃ ｎ ｗ ｙ ｎ ｅ ｅ ｏｍ ｃ ｆ ｉｕｌ ｃｉ ，ｘｅｔｕ ｌｉ ｏｅ ｅｅ ｌｅｃｍａ ｏ ． ｈ Ａ ｍｃｌ ｏ ｅ ｅ ｅ ｆ ｉ ｔ ａｓｏｔ ｅｔ ｒ ｒ ａ ｅ ｒ ａｍａｈ ｅｅｃｐｓ ｔｉｎ ｔ ｓ ｇｎｒ ｎｈ ｒ ｔ ｌ Ｔ ｉ ｈ ｅ ｒｆ ｉ ｆ ｅ ｔ ｕ ｈ ｐ ｆ ｎ ｏ ｖｔ ｎ ｉｚ ｇｈ ａｂ ｋｏ ｓ ｓ
Ｐ ｒｏ ｍａ ｃ ｎ ｎ ｆＸｅ － ａ ｅ ６Ｖｉｔ ａ ａ ｈ ｎ ｅ ｆ ｒ ｎ ｅＴｕ ｉ ｇｏ ｎ ｂ ｓ ｄ Ｘ８ ｒ ｕ ｌ Ｍ ｃ ｉｅ
性能测试(LoadRunner)
开始 分析应用系统 定义压力测试的对象和目标 测试计划评审 编写测试案例 测试环境的搭建 测试数据的准备 测试工具的准备 录制脚本，增强脚本 实施方案，监视系统资源 分析测试结果 是否可以接受
Part4 . L oa d R u n n e r 应 用
2、录制、编辑及调试脚本 性能测试最重要的一步是生成虚拟用户脚本
Virtual User Generator
事务：为了衡量服务器的性能，需要定义事务；如：数据查询 操作，为了衡量服务器执行查询操作的性能，需要把这个操作 定义为一个事务，这样在运行测试脚本时，LoadRunner运行 到该事务的开始点时，LoadRunner就会开始计时，直到运行 到该事务的结束点，计时结束。这个事务的运行时间在结果中 会有反映。
数据准备时根据测试需要，在执行测试之前在被 测系统种加入复合要求的数据。 数据准备方法： 1、手工：要加入的数据量比较少的情况下可以手工 在系统中加入。 2、使用LR或其他自动化测试工具：在数据量比较多 的情况下就要使用工具，录制脚本反复迭代运行脚本 或在场景中运行脚本； 3、数据直接写入数据库：这种方法使用sql语句（或 存储过程）实现数据批量写入数据库；
Part1.性 能 测 试 简 介
性能测试的定义
（5）思考时间：Think Time，也被称为“休眠时间”，从业务的角度来说，这个时间指的是用户在进行操作时， 每个请求之间的间隔时间。从自动化测试实现的角度来说，要真实地模拟用户操作，就必须在测试脚本中让各个 操作之间等待一段时间，体现在脚本中，具体而言，就是在操作之间放置一个Think 的函数，使得脚本在执行两 个操作之间等待一段时间。 （6）TPS ：Transaction per second，每秒钟系统能够处理的交易或者事务的数量。它是衡量系统处理能力的重要 指标。 （7）HPS：点击率Hit Per second ，每秒钟用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个 指标，WEB应用是"请求—响应"模式，用户发出一次申请，服务器就要处理一次，所以点击是WEB应用能够处理 的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对 服务器的压力越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，这里的点 击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求。
R L 算 法 介 绍 及 比 较
点击率预估中的FM算法&FFM算法特征决定了所有算法效果的上限，而不同的算法只是离这个上限的距离不同而已CTR方法概览广义线性模型+人工特征组合（LR+FeatureEngineering）非线性模型（GBDT，FM，FFM，DNN，MLR）广义线性模型+非线性模型组合特征（模型融合，常见的是LR+GBDT）其中 2（非线性模型）又可以分为：矩阵分解类（FM，FFM）回归类（GBDT，MLR）神经网络类（DNN）FM算法（Factorization Machine）一般翻译为“因子分解机”，2010年，它由当时还在日本大阪大学的Steffen Rendle提出。
此算法的主要作用是可以把所有特征进行高阶组合，减少人工参与特征组合的工作，工程师可以将精力集中在模型参数调优。
FM只需要线性时间复杂度，可以应用于大规模机器学习。
经过部分数据集试验，此算法在稀疏数据集合上的效果要明显好于SVM。
要解决的问题假设一个广告分类问题，根据用户和广告位相关的特征，预测用户是否点击了广告。
Clicked?26-11-15"Clicked?"是label，Country、Day、Ad_type是特征。
由于三种特征都是categorical类型的，需要经过独热编码（One-Hot Encoding）转换成数值型特征。
Clicked?Country=USACountry=ChinaDay=26-11-15Day=1-7-14Day=19-2-15Ad_type=MovieAd_type=Game经过one-hot编码之后，特征变得稀疏，上边实例中每个样本有7维的特征，但平均仅有3维为非0值，在电商场景中预测sku是否被点击的过程中，特征往往要比上例中多的多，可见数据稀疏性是工业环境中不可避免的问题。
另外一个问题就是特征在经过one-hot编码之后，维度会变得非常大，比如说三级品类有3k个，那么sku的所属三级品类特征经过编码之后就会变成3k维，特征空间就会剧增。
Oracle的性能测试经验总结
前段时间，在阿里妈妈新机房压力测试过程中用到了LR测试ORACLE，跟DBA一起在杭州网通新机房进行1000用户的压力模拟测试。
整个压力测试耗时两天。
以下是一些经验：1）压力测试过程中发现一些SQL脚本执行非常慢，进行了优化。
2）最好并发测试，否则服务基本上没有什么压力。
3）先从100用户开始，再慢慢向上加，直到CPU的承载达到90%以上。
查看系统的性能情况，包括TPS，响应时间，和内存等。
还包括oracle服务器的I/O流量和交易数。
这个方案是参考了淘宝的机房性能测试方案，下面是性能测试的具体步骤：oracle的性能测试主要是模拟大量的sql语句操作，来对数据库服务器进行加压。
在测试前，需要准备以下要模拟的sql语句，测试脚本，并将测试控制机、测试加压机、被测数据库服务器准备妥当。
脚本协议选择oracle（2-Tier），将所有要模拟的sql语句放在一个sql文件内，使用sql-plus 来操作数据库载入，使用loadrunner来录制。
录制好之后就是修改脚本了，首先在vdf.h文件中定义变量（static void FAR * OraBind1;），定义参数(static LRD_VAR_DESC UID ={LRD_VAR_DESC_EYECAT, 1, 10, LRD_DBTYPE_ORACLE, {1, 1, 0},DT_SF_STRIPPED_SPACES};)。
为什么要在这里定义而不直接只用参数化呢？因为那样会对加压机造成很大的压力，不利于测试。
这里需要根据你的脚本来变化，你在脚本中使用了多少变量，多少参数，那么你就在要这里定义多少。
接下来修改脚本的，将一次性的登陆登出放在init和end中，使用lrd_assign和lrd_ora8_bind_placeholder命令替代参数，如lrd_ora8_stmt(OraStm6, "SELECT COUNT(*) as counter FROM ***** WHERE ***_id="":U and ( status = 0 or ""status is null)", 1, 0, 0);lrd_assign(&UID , "{UID}", "", 0, 0);lrd_ora8_bind_placeholder(OraStm6, &OraBind1, "U", &UID , 0, 0, 0);这样，脚本就差不多大功告成了。
keras系列（一）：参数设置
keras系列（一）：参数设置常用的权重/偏置初始化常数初始化为了在伪代码中形象化，让我们考虑一个具有64个输入和32个输出的神经网络的任意一层。
W = np.zeros((64, 32))W = np.ones((64, 32))W = np.ones((64, 32)) * C虽然常量初始化很容易理解和理解，但使用这种方法的问题是，我们几乎不可能打破激活的对称性。
因此，它很少被用作神经网络的权重初始化器。
均匀/正态分布W = np.random.uniform(low=-0.05, high=0.05, size=(64, 32)) W = np.random.normal(0.0, 0.5, size=(64, 32))在神经网络中，均匀分布和正态分布都可以用来初始化权值;然而，我们通常使用各种启发式来创建更好的初始化方案。
LeCun 均匀/正态分布在这里，作者定义了一个参数Fin(称为fan in，或者是层的输入数)和Fout(称为fan out，或层的输出数)。
使用这些值，我们可以应用统一的初始化。
F_in = 64F_out = 32limit = np.sqrt(3 / float(F_in))W = np.random.uniform(low=-limit, high=limit, size=(F_in, F_out))我们也可以用正态分布。
Keras库使用一个截断的正态分布来构造上下限，以及零均值。
F_in = 64F_out = 32limit = np.sqrt(1 / float(F_in))W = np.random.normal(0.0, limit, size=(F_in, F_out))Glorot/Xavier 均匀/正态分布在Keras库中使用的默认权值初始化方法称为Glorot初始化或Xavier初始化。
对于正态分布，其极限值是由平均的Fin和Fout组合而成，然后取平方根。
基于串联协作法的RLV机翼参数优化设计
已知高声速飞行马赫数 Ｍａ １ ， ＝ ５ 亚声速飞行攻角 ｃ １。假 点集 合 。 ￣ ５， ＝ 设运载器质心位置系数 ｘ．ｏ ５互 。优化问题 的数学模型为 ： ， ．， ０ ￣ ６ － － 证 明： 目标 函数 厂 设 是可测函数 ， 为可行域 ， 算法所产生的
ｍｉ ｍ ｎ
》ｓｒ ｅ ｃ ｅｔｏａ ｏ ｔ ｅｏｔ ｉ ｉ ｒ ｅ ． ｄｐｉ ｒ ｌ ｏａｏ ｉ ｔ ｅｙ｛ ｏ ｅｄ ｅｔｏ ｔ ｌ ｒｈ ｉ ｔ ｐｉ ｚ ｏ ｐｏ ｓ弛ｅａｏｔ ｎｏ ｓ ｉ ｌ ｒ ｖ ｓａ ｇ ｎ ｆ ｓｆ ｈ ｗ ｇ ｉｍ ｎ ｈ ｍａ ｎ ｃｓ ｔ ｏ ｆ ｅａ ｃ ｌ ａ ｅ ｒ ｂ ｔ ｔ
陷， 如计算精度不高 ， 陛不够 良 ， 稳健 好 易陷入局部最优等问题。为 翼平面形状的前缘后掠角 Ａ 后缘 后掠 角 Ａ 外翼暴露根弦长
， 。 ， 解 决 以上 问题 ， 文彩 提 出了 多方 法协 作 优 化方 法 １ Ｍｕ ｉ ｅ ｏ ｃ 以及 根 梢 比 Ａ 根 据 文献 日小 型有 翼 可 重复 使用 运 载 器机 翼 结 罗 ２ １ ｈｍ ｔ ｄ （ ｈ Ｃ ｌｂ ｒｔｅ ｐｉ ｚｔ ｎＡｇｒｈ 简 称 ＭＣ Ａ）而 ＭＣ Ａ作 为 构 重量 ｍ 与 几何 参 数 的关 系 为 ： ｏｌ ｏａｖ ｔ ａｏ ｌｏ ｔｍ， ａ ｉ Ｏ ｍｉ ｉ ｉ Ｏ ， Ｏ
Ｏ １ Ａ ０３ ． ＿
３ 求解 方 Leabharlann ３１单纯 形调优 法及 遗传算法 ．
单纯形涮优法（ ｅ ｅ Ｍｅｄ法 ） Ｎｌ ｒ ａ ｄ－ 是一种针对无约束最优化 的直接方法 ， 在这种 方法 中 ， 给定 Ｒ 中一个单纯形后 ， 求出 ｎ ｌ ＋ 顶点上 的函数值 ， 确定出有最大函数值的点（ 称为最高点 ） 和最小 函数值的点 （ 称为最低点 ）然后通过反射 、 ， 扩展 、 压缩等方法 （ 几 种方法不一定同时使用 ） 出一个较好点 ， 求 用它取代最 高点 ， 构成 新 的单纯形 ， 或者通过向最低点收缩形成新 的单纯形 ， 用这样 的 方法逼近极小点Ｈ 。由于单纯形 的迭代运用了较 多点 的目标 函数 值信息 ，因而单纯形 向最优点方向翻动 的效果更加稳定 ，所 以 Ｎ ｌｅ— ｅｄ法是一种使用较为广泛 的直接搜索局部优化法闭 ｅ ｒＭ ａ ｄ ，
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈。这时相关开发人
员、数据库管理员、系统管理员、网络管理员等就需要根据性能测试分析人员提出的意见同
性能分析人员共同分析确定更细节的内容，相关人员对系统进行调整以后，性能测试人员继
续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后系
统的性能是否有提升。有一点需要提醒大家，就是在进行性能调整的时候，最好一次只调整
一项内容或者一类内容，避免一次调整多项内容而引起性能提高却不知道是由于调整那项关
键指标而改善性能的。那么在进行系统的调优过程中是否有什么好的策略来知道我们工作呢？
经过多年的工作，作者的经验是按照由易到难的顺序对系统性能进行调优。
系统调优由易到难的先后顺序如下：
1. 硬件问题
2. 网络问题
3. 应用服务器、数据库等配置问题
4. 源代码、数据库脚本问题
5. 系统构架问题
硬件发生问题是最显而易见的，如果CPU不能满足复杂的数学逻辑运算，可以考虑更换CPU，
如果硬盘容量很小，承受不了很多的数据可以考虑更换高速、大容量硬盘等。如果网络带宽
不够，可以考虑对网络进行升级和改造，将网络更换成高速网络；还可以将系统应用与平时
公司日常应用进行隔离等方式，达到提高网络传输速率的目的。很多情况下，系统性能不是
十分理想的一个重要原因就是没有对应用服务器、数据库等软件进行调优和设置引起来的，
如：调整堆内存和扩展内存的大小，数据库引入连接池技术等。源代码、数据库脚本在上述
调整无效的情况下，您可以选择的一种调优方式，但是由于设计到对源代码的改变有可能会
引入缺陷，所以在调优以后，不仅需要对性能的测试还要对功能进行验证，是否正确。这种
方式需要通过对数据库建立适当的索引，以及运用简单的语句替代复杂的语句，从而达到提
高语句运行效率的作用，还可以在编码过程中选择好的算法，减少响应时间，引入缓存等技
术。最后，在上述尝试都不见效的情况下，您就需要考虑现行的构架是否合适，选择效率高
的构架，但由于构架的改动比较大，所以您应该慎重对待。