知识大全 影响性能的测试报告（数据库版）
Posted 知
篇首语：临文乍了了，彻卷兀若无。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 影响性能的测试报告（数据库版）相关的知识，希望对你有一定的参考价值。
引言 前提 项目组里无用到SPRING进行事务的管理 项目里以功能划分到每个人手里 形成了BO DAO ACTION VIEW都是单人负责 在DAO中每个动作都以 封闭式的形式存在 问题 造成事务的不连贯性 功能是做出来了 性能问题迟早暴露 测试 主要针对程序频繁请求数据库连接对WEB应用所造成影响做一个测试 先做必要的说明 一步步引入正题 先从性能瓶颈开始 性能瓶颈 所有的应用程序都存在性能瓶颈 为了提高应用程序的性能 就要尽可能的减少程序的瓶颈 以下是在JAVA程序中经常存在的性能瓶颈 > 了解了这些瓶颈后 就可以有针对性的减少这些瓶颈 从而提高JAVA应用程序的性能 数据库连接池工作原理 关于连接池的实现原理测试方案 经过资料的收集与APACHE DBCP里连接池的查阅 对现有的连接池工作原理有两种方式 数据库预先设置配置好的连接数 待得到用户请求连接 传出一个连接 而后为了保持供应数再提前创建连接 即提前预备连接数供请求 比如 有 个通行道代表最大激活的连接数 最小 个闲置连接数 也就是说连接池里始终预备了 个可随时提供的连接 连接的创建开销是比较大的 连接池的存在就是了能够最小化的解决创建所等待的时间 O O * * * 如上图 当 分配出去时由于池中连接数剩一个 为保持最小闲置 会自动创建一个新的连接以防止再次请求等待创建的时间 这样确实减少了等待的时间 但是数据库创建的开销方面并未得到解决 如果把 比喻成汽车 那么这种情况下每量车都是一次性使用 被请求后下一个连接将是 来接替 那么如何能够重复利用 减少数据库开销 于是引出第二种方式 回收使用完后的连接 放回到池中进行循环利用 这么做必须能保证 点 一 使连接能够保持有效的回收 二 约束使用者使用释放的动作 而不是直接把连接close 笔者使用的是APACHE DBCP里BasicDataSource的连接池基本实现 经过代码与测试结果显示 其工作方式是基于二的 BasicDataSource测试用例 下面展示了一个测试用例 测试结果 第 组数据: 并发应用数 模拟连接数 运行平均耗时 共使用 个连接 运行平均耗时 共使用 个连接 运行平均耗时 共使用 个连接 运行平均耗时 共使用 个连接 运行平均耗时 共使用 个连接 第 组数据共执行 次;平均耗时为 毫秒 平均使用 个连接 第 组数据: 并发应用数 模拟连接数 运行平均耗时 共使用 个连接 运行平均耗时 共使用 个连接 运行平均耗时 共使用 个连接 运行平均耗时 共使用 个连接 运行平均耗时 共使用 个连接 第 组数据共执行 次;平均耗时为 毫秒 平均使用 个连接 第 组数据: 并发应用数 模拟连接数 运行平均耗时 共使用 个连接 运行平均耗时 共使用 个连接 运行平均耗时 共使用 个连接 运行平均耗时 共使用 个连接 运行平均耗时 共使用 个连接 第 组数据共执行 次;平均耗时为 毫秒 平均使用 个连接 每次测试的结果都可能不同 但是所得到的结论是一致的 数据显示不合理的请求使用连接严重的影响应用所能承受的并发数量 响应的时间也因此受到影响 目前普遍存在的问题 没有把事务控制好 一般会出现以下的情况 事务() 流程 (); 流程 (); 可以看出流程 里都是单独创建连接 并在自己的流程里完成操作 如果在流程 里出现异常 那么流程 所做的操作是不可恢复的 如果能控制在事务范围内 如 事务() Connection con; 流程 (con); 流程 (con); con close(); 那么数据库少提供一个连接 事务的完成性也得到体现 在并发数量大的时候 效率上就有非常明显的区别 解决方案 尽量保持少的请求 如DAO中有update()方法 则应再扩展一个方法update(Connection conn) 在业务逻辑事务里调用update(Connection conn) 一般情况下调用update() 对于数据不变的情况采用缓存技术 或部分缓存技术 可参照一些相关的开源的项目（JIVE） cha138/Article/program/Java/hx/201311/27107相关参考