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

上传人:b****1 文档编号:12471476 上传时间:2023-04-19 格式:DOCX 页数:9 大小:19.76KB
下载 相关 举报
应用系统项目优化方案研究.docx_第1页
第1页 / 共9页
应用系统项目优化方案研究.docx_第2页
第2页 / 共9页
应用系统项目优化方案研究.docx_第3页
第3页 / 共9页
应用系统项目优化方案研究.docx_第4页
第4页 / 共9页
应用系统项目优化方案研究.docx_第5页
第5页 / 共9页
点击查看更多>>
下载资源
资源描述

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

《应用系统项目优化方案研究.docx》由会员分享,可在线阅读,更多相关《应用系统项目优化方案研究.docx(9页珍藏版)》请在冰豆网上搜索。

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

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

 

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

 

版本:

1。

0

文档描述

文档名称

**项目优化方案

当前版本

V1.0

内容简介

对移动客服项目进行多角度优化

文档变更

日期

版本

说明

作者

审核

2013/4/18

V1。

0

初稿

kytfox

1引言

1.1背景

系统的数据量增长越来越快,系统的瓶颈问题越来越严重,影响了系统的正常使用,导致用户对系统操作方面非常不满意。

系统在前期已经进行过一些优化:

1.系统内部优化:

页面框架变更、查询功能优化、sql表中加入索引等常规优化

2.组件级调优:

数据库、中间件一些常用参数的配置

取得一些效果,但在数据量成级数增长后,需要一些系统性的全面优化方案,以解决系统性能问题.

1.2目的

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

1.3术语缩略语

序号

术语/缩略语

全称及说明

1

2

3

1.4参考资料

1.5适用人群

项目管理人员、架构人员、配置管理人员、开发人员

 

2现状分析

在系统缓慢的4.11抓取当天的日志请求(POST)纪录,小时为单位,提取大于8秒请求纪录:

时间

纪录数

8点—-—-—9点

110

9点-———-10点

216

10点-—--—11点

137

11点-—-——12点

200

12点--—-—13点(饭点)

78

13点———--14点

136

14点-——--15点

113

15点--——-16点

105

16点--—-—17点

288

17点——--—18点(下班)

53

每个小时很平均地分布着一些8秒以上的请求,表明系统有一些瓶颈点还没有被优化。

3调优总体方案汇总

3.1应用程序调优(目前采用)

应用程序代码的性能占总体性能的80%,代码写得好坏决定了系统是否能够正常运营。

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

3.1.1Java代码优化

3.1.2页面代码优化

3.1.3Sql语句优化(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文件:

修改前:

if"%JAVA_VENDOR%"==”Sun"(

setWLS_MEM_ARGS_64BIT=—Xms256m-Xmx512m

setWLS_MEM_ARGS_32BIT=-Xms256m—Xmx512m

)else(

setWLS_MEM_ARGS_64BIT=-Xms512m-Xmx512m

setWLS_MEM_ARGS_32BIT=-Xms512m-Xmx512m

setMEM_PERM_SIZE_32BIT=-XX:

PermSize=48m

setMEM_MAX_PERM_SIZE_32BIT=-XX:

MaxPermSize=128m

修改后:

if"%JAVA_VENDOR%”=="Sun"(

setWLS_MEM_ARGS_64BIT=-Xms512m–Xmx1024m

setWLS_MEM_ARGS_32BIT=—Xms512m–Xmx1024m

)else(

setWLS_MEM_ARGS_64BIT=-Xms1024m–Xmx1024m

setWLS_MEM_ARGS_32BIT=—Xms1024m–Xmx1024m

setMEM_PERM_SIZE_32BIT=-XX:

PermSize=128m

setMEM_MAX_PERM_SIZE_32BIT=—XX:

MaxPermSize=256m

说明:

具体修改值根据实际物理内存确定

Ø—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中添加如下:

setJAVA_OPTIONS=%JAVA_OPTIONS%—Dweblogic。

threadpool.MinPoolSize=2000

setJAVA_OPTIONS=%JAVA_OPTIONS%—Dweblogic。

threadpool。

MaxPoolSize=4000

说明:

JDK5.0版本以后每个线程栈大小为1M,但是操作系统对一个进程内的线程数还是有限制的,不能无限生成。

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

3.2.1.3数据库连接池连接数设置

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

点击数据源,进入后选择连接池,初始默认值为:

初始容量:

1最大容量:

15容量增长:

1

更改为:

初始容量:

50最大容量:

100容量增长:

5

说明:

设置前得设置数据库的最大并发线程数(下面有介绍Oracle数据库线程数设置方法),因为weblogic节点的连接池最大连接数之和不能大于数据库的最大线程数.

Ø初始容量:

要在创建连接池时创建的物理连接数。

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

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

Ø最大容量:

此连接池可容纳的最大物理连接数.

Ø容量增长:

将新连接添加到连接池时创建的连接数。

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

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.5StuckThreadMaxTime参数设置

如果请求较多,很有可能会导致weblogic的线程阻塞,严重会引起weblogic挂起现象.

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

3.2.2JVM优化

3.3数据库调优(目前采用)

3.3.1合理建立数据库

3.3.2SQL语句的优化

3.3.3数据库对象存储方式的优化

3.3.4内存的优化

3.3.5I/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

 

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高中教育 > 语文

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1