应用系统项目优化方案研究

应用系统项目优化方案研究
版本：1.0
文档描述
文档变更
目录
1引言 (6)
1.1背景 (6)
1.2目的 (6)
1.3术语缩略语 (6)
1.4参考资料 (7)
1.5适用人群 (7)
2现状分析 (8)
3调优总体方案汇总 (9)
3.1应用程序调优（目前采用） (9)
3.1.1Java代码优化 (9)
3.1.2页面代码优化 (9)
3.1.3Sql语句优化（V2.2） (9)
3.1.4应用架构代码优化 (9)
3.2容器调优（目前采用） (9)
3.2.1应用服务器优化（weblogic优化） (9)
3.2.2JVM优化 (12)
3.3数据库调优（目前采用） (13)
3.3.1合理建立数据库 (13)
3.3.2SQL语句的优化 (13)
3.3.3数据库对象存储方式的优化 (13)
3.3.4内存的优化 (13)
3.3.5I/O 优化 (13)
3.3.6使用大表分区技术（采用） (13)
3.3.7优化回滚段设计 (13)
3.3.8优化重做日志文件 (13)
3.4操作系统调优 (13)
3.5性能监控 (13)
3.5.1操作系统监控 (13)
3.5.2数据库监控 (13)
3.5.3中间件监控 (13)
3.5.4代码监控 (14)
3.5.5业务监控 (14)
3.6拆分与扩展 (14)
3.6.1硬件增加 (14)
3.6.2应用系统拆分 (14)
3.6.3业务拆分 (14)
3.6.4数据分割 (15)
3.7接口优化 (16)
4目前方案 (17)
1引言
1.1 背景
系统的数据量增长越来越快，系统的瓶颈问题越来越严重，影响了系统的正常使用，导致用户对系统操作方面非常不满意。

系统在前期已经进行过一些优化：
1. 系统内部优化：页面框架变更、查询功能优化、sql表中加入索引等常规优化
2. 组件级调优：数据库、中间件一些常用参数的配置
取得一些效果，但在数据量成级数增长后，需要一些系统性的全面优化方案，以解决系统性能问题。

1.2 目的
本文主要是针对系统的一个整体的优化，不涉及代码级别的。

1.3 术语缩略语
1.4 参考资料
1.5 适用人群
项目管理人员、架构人员、配置管理人员、开发人员
2现状分析
在系统缓慢的4.11抓取当天的日志请求（POST）纪录，小时为单位，提取大于8秒请求纪录：
每个小时很平均地分布着一些8秒以上的请求，表明系统有一些瓶颈点还没有被优化。

3调优总体方案汇总
3.1 应用程序调优（目前采用）
应用程序代码的性能占总体性能的80%，代码写得好坏决定了系统是否能够正常运营。

主要有以下几部分优化工作。

3.1.1 Java代码优化
3.1.2 页面代码优化
3.1.3 Sql语句优化（V2.2）
3.1.4 应用架构代码优化
分页处理优化、本地缓存应用
3.2 容器调优（目前采用）
3.2.1 应用服务器优化（weblogic优化）
3.2.1.1 设置JDK内存
修改weblogic\user_projects\domains\base_domain\bin下的setDomainEnv.cmd文件：修改前：
修改后：
说明：具体修改值根据实际物理内存确定
-Xmx3550m：设置JVM最大堆内存为3550M。

-Xms3550m：设置JVM初始堆内存为3550M。

此值可以设置与-Xmx相同，以避免每次JVM动态分配内存所浪费的时间。

-XX:PermSize=256M：设置堆内存持久代初始值为256M。

(貌似是Eclipse等IDE 的初始化参数)
-XX:MaxPermSize=512M：设置持久代最大值为512M。

32位操作JDK内存系统：最大可设置2G，如果设置过大，会导致服务无法启动 64位操作JDK内存系统：最大设置为物理内存的60~80%
3.2.1.2 设置线程数
修改weblogic\user_projects\domains\base_domain\bin下的setDomainEnv.cmd中在JAVA_OPTIONS中添加如下：
说明：
JDK5.0版本以后每个线程栈大小为1M，但是操作系统对一个进程内的线程数还是有限制的，不能无限生成。

32位操作系统根据JVM最大堆内存设置；64位操作系统经验值在3000~5000左右。

3.2.1.3 数据库连接池连接数设置
受Oracle数据库连接数的影响，可以参照同一时间连接数据库的用户数量，进行设置，数据库的最大连接数不能小于高峰时期同一时间连接用户的数量。

点击数据源，进入后选择连接池，初始默认值为：
更改为：
说明：
设置前得设置数据库的最大并发线程数（下面有介绍Oracle数据库线程数设置方法），因为weblogic节点的连接池最大连接数之和不能大于数据库的最大线程数。

初始容量：要在创建连接池时创建的物理连接数。

如果无法创建这一数量的连接，创建此连接池的操作将会失败。

此连接数也是连接池将保持的最小可用物理连接数。

最大容量：此连接池可容纳的最大物理连接数。

容量增长：将新连接添加到连接池时创建的连接数。

不再有可用的物理连接来满足连接请求时，WebLogic Server 会创建该数量的附加物理连接并将它们添加到连接池中。

3.2.1.4 积压数和超时
接受积压：300
登录超时：5000
说明：
接受积压：对于此服务器的常规和SSL 端口，应该允许的新TCP 连接请求的积压数量。

将积压设置为0 可以防止此服务器接受某些操作系统上的所有传入连接。

MBean 属性：ServerMBean.AcceptBacklog。

最小值：0。

通常情况下，一次不要增加太多，Bea公司建议每次增加默认值的25％，直到系统不在出现这个错误为止。

登录超时：此服务器的默认常规(非SSL) 监听端口的登录超时。

这是允许建立新连接的最长时间。

如果值为0，表示无最大值。

MBean 属性：ServerMBean.LoginTimeoutMillis 最小值：0。

最大值：100000。

安全值：5000
3.2.1.5 StuckThreadMaxTime参数设置
如果请求较多，很有可能会导致weblogic的线程阻塞，严重会引起weblogic挂起现象。

修改StuckThreadMaxTime参数，将默认的600s改成1200s，或者其它适合的值。

3.2.2 JVM优化
3.3 数据库调优（目前采用）
3.3.1 合理建立数据库
3.3.2 SQL语句的优化
3.3.3 数据库对象存储方式的优化
3.3.4 内存的优化
3.3.5 I/O 优化
3.3.6 使用大表分区技术（采用）
3.3.7 优化回滚段设计
3.3.8 优化重做日志文件
3.4 操作系统调优
本章欠奉，由于此项工作属于主机组的工作，暂不讨论。

3.5 性能监控
3.5.1 操作系统监控
对所有服务器的系统进行监控，及时发现问题
3.5.2 数据库监控
对数据库运行进行监控
3.5.3 中间件监控
对weblogic进行监控
3.5.4 代码监控
通过分析工具，对方法调用进行统计，及时了解代码运行情况
3.5.5 业务监控
对业务流程中的关键点进行打点开发，对这些点进行分析
3.6 拆分与扩展
基于目前的系统部署和使用情况，从业务方面对系统进行精细化处理，硬件扩展以应对大并发的情况出现
3.6.1 硬件增加
对应用做集群部署后，根据并发情况增加服务器数量，以应对大并发的情况出现
3.6.2 应用系统拆分
对部署在一个应用服务器中的多个应用进行单独部署，增加各应用对资源的独享，避免多个应用互相影响。

3.6.3 业务拆分
业务流程
目前情况
改造后
系统功能
把报表等大数据统计功能，从应用系统中分拆出来，减小应用系统的压力
3.6.4 数据分割
3.6.
4.1读写分离分布技术
将实时更新的数据库同步复制到另外一个库中，该库以读操作为主，而索引则建立在只读库中，实现了简单的读写分离．
3.6.
4.2垂直分割技术
分出多个数据库，不同数据库运行不同业务
3.6.
4.3水平分割技术
根据业务颗粒进行横向分割
3.6.
4.4虚拟化存储技术
让存储统一管理负载均衡。

3.6.
4.5缓存技术
在系统应用各层加入缓存，缓存系统常用的数据，以保证系统达到高并发的要求
本地缓存可以用ehcache
如果单独部署缓存，可以考虑memcache或redis
3.7 接口优化
4第一阶段方案
1. 应用程序调优---sql调优
2. 数据库调优级—--分区（聂大威）
3. 容器调优
4. 在条件允许的情况下进行拆分与扩展
应用系统部署拆分—再议
报表分离—做了一部分
业务监控----
缓存技术----基础数据缓存
EHCACHE。