JEE应用服务器性能优化方案.ppt

J2EE应用服务器性能优化方案 常见性能问题影响J2EE系统性能的可能因素JVM介绍线程介绍应用服务器性能调优简介金蝶Apusic性能调优Http服务性能调优数据库连接池性能调优线程池性能调优工具使用说明案例分析定位系统性能瓶颈 3 J2EE常见问题表现 页面访问速度慢页面无法访问系统性能整体下降应用服务器崩溃JVM崩溃 不管症状是什么 如果你想让程序恢复正常运行 你一般都需要重新启动应用服务器 4 J2EE常见问题分析逻辑 页面是真的访问不到了吗 是性能问题 还是崩溃 环境和以前发生哪些变化 时点状态信息是否捕捉 问题出现的时候需要冷静 问题分析的时候需要用排除法 对待问题因素需要做减法 5 Http1 1协议规范中的StatusCode 1xx 信息提示100 继续 101 切换协议 2xx 成功这类状态代码表明服务器成功地接受了客户端请求 200 确定 客户端请求已成功 201 已创建 202 已接受 203 非权威性信息 204 无内容 205 重置内容 206 部分内容 3xx 重定向客户端浏览器必须采取更多操作来实现请求 302 对象已移动 304 未修改 307 临时重定向 4xx 客户端错误400 错误的请求401 登录失败403 禁止访问404 未找到405 用来访问本页面的HTTP方法 GET POST PUT等 不被允许 方法不被允许 406 客户端浏览器不接受所请求页面的MIME类型 407 要求进行代理身份验证 412 前提条件失败 413 请求实体太大 414 请求URI太长 415 不支持的媒体类型 416 所请求的范围无法满足 417 执行失败 5xx 服务器错误500 内部服务器错误 501 页眉值指定了未实现的配置 502 Web服务器用作网关或代理服务器时收到了无效响应 503 服务不可用 504 网关超时 505 HTTP版本不受支持 6 J2EE常见性能问题 J2EE应用系统性能涉及多个层面 7 影响J2EE系统性能的可能因素 硬件 网络操作系统虚拟机应用服务器数据库应用框架业务逻辑其他 8 影响J2EE系统性能的可能因素 系统资源利用不足系统未能实现对CPU的充分利用无论负载如何增加 均不能完全利用CPU随用户增加 系统响应时间增加 而吞吐量保持不变甚至减少可能原因系统其他资源 非CPU 负载过大造成瓶颈 网络 数据库 驱动程序等 系统或者应用程序的串行化 Serializable 9 影响J2EE系统性能的可能因素 突发的资源占用称为burstiness系统在某些时段有很高的实用率 而在其他的时间点却很 安静 可能原因应用程序同步 synchronized wait notify notifyAll 虚拟机垃圾回收数据库死锁网络问题磁盘IO 10 影响J2EE系统性能的可能因素 CPU利用率过高CPU的利用率超过95 处于饱和状态可能原因应用程序效率低下负载过重 处于排队状态 11 影响J2EE系统性能的可能因素 服务停顿 退出服务停顿也指服务的挂起 服务器长时间不作响应服务退出指整个虚拟机实例非正常退出可能原因应用程序死锁线程锁定资源1 然后等待锁定资源2 另一个线程锁定资源2 然后等待锁定资源1线程耗尽高并发下线程池设置不够大 或者线程池出现异常 无法重用数据库死锁数据库死锁发生时 将影响连接池或当前业务的进行 内存泄露Java中的内存泄露是由于对象句柄丢失 对象处于游离状态而不能被垃圾回收器回收垃圾回收大对象或过多的cache对象timeout 将导致过长的垃圾回收过程JVM异常虚拟机底层代码 本地代码 可能存在bug 在某些尖锐环境下触发 常见性能问题影响J2EE系统性能的可能因素JVM介绍线程介绍应用服务器性能调优简介金蝶Apusic性能调优Http服务性能调优数据库连接池性能调优线程池性能调优工具使用说明案例分析定位系统性能瓶颈 13 JVM基本概念 堆 Heap 是Java程序的对象生活的地方 包含活的对象 死的对象以及剩余内存 当对象不能被运行中的程序的指针所到达时 这些对象成为 垃圾 JVM的堆大小决定了VM花费在收集垃圾上的时间和频度 对象生存的时间越长 需要的收集时间也越长 因此 收集变慢 14 JVM划分 年轻的一代 Younggeneration 包括EDEN和2个幸存者空间 出发地和目的地theFromspaceandtheTospace 用于存放 早逝 对象 即瞬时对象 例如 在创建对象时或者调用方法时使用的临时对象或局部变量 老一代 Oldgeneration 用于存放 驻留 对象 即较长时间被引用的对象 往往体现为一个大型程序中的全局对象或长时间被使用的对象 永久的一代 Permanentgeneration 用于存放 永久 对象 这些对象管理着运行于JVM中的类和方法 15 SUNJVM内存管理方式 简单说 Young保存刚实例化的对象 当该区被填满时 GC会将对象移到Old区 复杂说 对象在EDEN出生就是被创建 当EDEN满了的时候 垃圾收集器就把所有在EDEN中的对象扫描一次 把所有有效的对象拷贝到第一个幸存者空间 同时把无效的对象所占用的空间释放 当EDEN再次变满了的时候 就启动移动程序把EDEN中有效的对象拷贝到第二个幸存者空间 同时 也将第一个幸存者空间中的有效对象拷贝到第二个幸存者空间 如果填充到第二个生存者空间中的有效对象被第一个生存者空间或EDEN中的对象引用 那么这些对象就是长期存在的 也就是说 他们被拷贝到老一代 若垃圾收集器依据这种小幅度的调整收集 minorcollection 不能找出足够的空间 就是象这样的拷贝收集 copycollection 就运行大幅度的收集 就是让所有的东西停止 stop the worldcollection 运行这个大幅度的调整收集时 垃圾收集器就停止所有在堆中运行的线程并执行清除动作 mark and sweepcollection 把新一代空间释放空并准备重启程序 16 SUNJVM内存管理方式 Eden和两片生存空间 survivorspaces 其中保证有一片空间在任何时间是空的 当垃圾收集发生时 Eden中的活的对象复制到下一片生存空间 对象就在生存空间之间复制 直到到达最大门限值 老化 然后复制到旧生代 Eden是新的对象分配的地方 很多对象分配以后很快成为垃圾 这些对象称为具有 infantmortality 17 SUNJVM内存管理方式 18 IBMJVM内存管理模式 IBM的JVM的机制有一点不同 它不是运行在一个巨大的继承HEAP中 它仅在一个单一的地区维护了所有的对象同时随着堆的增长来释放内存 这个堆是这样运行的 在一开始运行的时候 它会很小 随着对象实例不断的填充 在需要执行垃圾收集的地方清除掉无效的对象同时把所有有效的对象紧凑的放置到堆的底部 常见性能问题影响J2EE系统性能的可能因素JVM介绍线程介绍应用服务器性能调优简介金蝶Apusic性能调优Http服务性能调优数据库连接池性能调优线程池性能调优工具使用说明案例分析定位系统性能瓶颈 20 认识JAVA线程 Java的线程线程是指能独立于程序的其它部分运行的执行单元 JAVA语言能够很好的实现多线程的程序 我们在调试程序 或者在开发后期需要做性能调优的时候 往往也需要了解当前程序正在运行的线程的状态 正在执行的操作 从而分析系统可能存在的问题 21 产生JAVA线程dump 产生JAVA线程dump在windows环境中 在启动程序的控制台里敲Ctrl Break 线程的dump会产生在标准输出中 缺省标准输出就是控制台 如果对输出进行了重定向 则要查看输出文件 在unix linux和MacOS环境中 在控制台中敲 Ctrl 或者 用 kill 3 或者 kill QUIT Pid是用所关注的JAVA进程号 您可以用 ps ef grepjava 找到 或者使用JDK5 0中的 jps v 命令获得 在各个操作系统平台 都可以用JDK5 0工具包中的jstack注意不同的JAVA虚机的线程DUMP的创建方法和文件格式是不一样的 不同的JVM版本 dump信息也有差别 在实际运行中 往往一次dump的信息 还不足以确认问题 建议产生三次dump信息 如果每次dump都指向同一个问题 我们才确定问题的典型性 22 线程分类 JVM线程 守护程序线程 在线程中 有一些JVM内部的后台线程 来执行譬如垃圾回收 或者低内存的检测等等任务 这些线程往往在JVM初始化的时候就存在 如下所示 23 线程分类 LowMemoryDetector daemonprio 10tid 0 x081465f8nid 0 x7runnable 0 x00000000 0 x00000000 CompilerThread0 daemonprio 10tid 0 x08143c58nid 0 x6waitingoncondition 0 x00000000 0 xfb5fd798 SignalDispatcher daemonprio 10tid 0 x08142f08nid 0 x5waitingoncondition 0 x00000000 0 x00000000 Finalizer daemonprio 10tid 0 x08137ca0nid 0 x4inObject wait 0 xfbeed000 0 xfbeeddb8 atjava lang Object wait NativeMethod waitingon ajava lang ref ReferenceQueue Lock atjava lang ref ReferenceQueue remove ReferenceQueue java 116 locked ajava lang ref ReferenceQueue Lock atjava lang ref ReferenceQueue remove ReferenceQueue java 132 atjava lang ref Finalizer FinalizerThread run Finalizer java 159 ReferenceHandler daemonprio 10tid 0 x081370f0nid 0 x3inObject wait 0 xfbf4a000 0 xfbf4aa38 atjava lang Object wait NativeMethod waitingon ajava lang ref Reference Lock atjava lang Object wait Object java 474 tjava lang ref Reference ReferenceHandler run Reference java 116 locked ajava lang ref Reference Lock 24 线程分类 用户级别的线程 如下所示 线程的状态 waitingoncondition线程的当前锁住的资源 线程的调用栈 Thread 1 prio 10tid 0 x08223860nid 0 xawaitingoncondition 0 xef47a000 0 xef47ac38 atjava lang Thread sleep NativeMethod attestthread MySleepingThread method2 MySleepingThread java 53 locked atestthread MySleepingThread attestthread MySleepingThread run MySleepingThread java 35 atjava lang Thread run Thread java 595 25 线程的状态 线程的状态是一个重要的指标 它会显示在线程Stacktrace的头一行结尾的地方 Runnable 该状态表示线程具备所有运行条件 在运行队列中准备操作系统的调度 或者正在运行 Waitoncondition该状态出现在线程等待某个条件的发生 具体是什么原因 可以结合stacktrace来分析 最常见的情况是线程在等待网络的读写 比如当网络数据没有准备好读时 线程处于这种等待状态 而一旦有数据准备好读之后 线程会重新激活 读取并处理数据 在Java引入NewIO之前 对于每个网络连接 都有一个对应的线程来处理网络的读写操作 即使没有可读写的数据 线程仍然阻塞在读写操作上 这样有可能造成资源浪费 而且给操作系统的线程调度也带来压力 在NewIO里采用了新的机制 编写的服务器程序的性能和可扩展性都得到提高 如果发现有大量的线程都在处在Waitoncondition 从线程stack看 正等待网络读写 这可能是一个网络瓶颈的征兆 因为网络阻塞导致线程无法执行 一种情况是网络非常忙 几乎消耗了所有的带宽 仍然有大量数据等待网络读写 另一种情况也可能是网络空闲 但由于路由等问题 导致包无法正常的到达 所以要结合系统的一些性能观察工具来综合分析 比如netstat统计单位时间的发送包的数目 如果很明显超过了所在网络带宽的限制 观察cpu的利用率 如果系统态的CPU时间 相对于用户态的CPU时间比例较高 如果观察到read write的系统调用的次数或者运行时间遥遥领先 这些都指向由于网络带宽所限导致的网络瓶颈 另外一种出现Waitoncondition的常见情况是该线程在sleep 等待sleep的时间到了时候 将被唤醒 26 线程的状态 Waitingformonitorentry和inObject wait Monitor是Java中用以实现线程之间的互斥与协作的主要手段 它可以看成是对象或者Class的锁 每一个对象都有 也仅有一个monitor 下面这个图 描述了线程和Monitor之间关系 以及线程的状态转换图 每个Monitor在某个时刻 只能被一个线程拥有该线程就是 ActiveThread 而其它线程都是 WaitingThread 分别在两个队列 EntrySet 和 WaitSet 里面等候在 EntrySet 中等待的线程状态是 Waitingformonitorentry 在 WaitSet 中等待的线程状态是 inObject wait 27 线程的状态 EntrySet 里面的线程 我们称被synchronized保护起来的代码段为临界区 当一个线程申请进入临界区时 它就进入了 EntrySet 队列 对应的code就像 synchronized obj 这时有两种可能性 该monitor不被其它线程拥有 EntrySet里面也没有其它等待线程 本线程即成为相应类或者对象的Monitor的Owner 执行临界区的代码 线程将处于 Runnable 的状态 该monitor被其它线程拥有 本线程在EntrySet队列中等待 线程DUMP会显示处于 waitingformonitorentry 如下所示 Thread 0 prio 10tid 0 x08222eb0nid 0 x9waitingformonitorentry 0 xf927b000 0 xf927bdb8 attestthread WaitThread run WaitThread java 39 waitingtolock ajava lang Object locked ajava util ArrayList atjava lang Thread run Thread java 595 28 线程的状态 WaitSet 里面的线程 当线程获得了Monitor 进入了临界区之后 如果发现线程继续运行的条件没有满足 它则调用对象 一般就是被synchronized的对象 的wait 方法 放弃了Monitor 进入 WaitSet 队列 只有当别的线程在该对象上调用了notify 或者notifyAll WaitSet 队列中线程才得到机会去竞争 但是只有一个线程获得对象的Monitor 恢复到运行态 在 WaitSet 中的线程 DUMP中表现为 inObject wait 类似于 Thread 1 prio 10tid 0 x08223250nid 0 xainObject wait 0 xef47a000 0 xef47aa38 atjava lang Object wait NativeMethod waitingon ajava util ArrayList atjava lang Object wait Object java 474 attestthread MyWaitThread run MyWaitThread java 40 locked ajava util ArrayList atjava lang Thread run Thread java 595 synchronized obj obj wait 29 线程小结 synchronized和monitor机制运用不当 可能会造成多线程程序的性能问题 临界区的设置 是为了保证其内部的代码执行的原子性和完整性 但是因为临界区在任何时间只允许线程串行通过 这和我们多线程的程序的初衷是相反的 如果在多线程的程序中 大量使用synchronized 或者不适当的使用了它 会造成大量线程在临界区的入口等待 造成系统的性能大幅下降 如果在线程DUMP中发现了这个情况 应该审查源码 改进程序 往往在你的程序中 会出现多个类似的线程 他们都有相似的DUMP信息 这也可能是正常的 比如 在程序中 有多个服务线程 设计成从一个队列里面读取请求数据 这个队列就是lock以及waitingon的对象 当队列为空的时候 这些线程都会在这个队列上等待 直到队列有了数据 这些线程被Notify 当然只有一个线程获得了lock 继续执行 而其它线程继续等待 在JDK5 0中 引入了Lock机制 从而使开发者能更灵活的开发高性能的并发多线程程序 可以替代以往JDK中的synchronized和Monitor的机制 但是 要注意的是 因为Lock类只是一个普通类 JVM无从得知Lock对象的占用情况 所以在线程DUMP中 也不会包含关于Lock的信息 30 案例分析 线程死锁 线程死锁 在多线程程序的编写中 如果不适当的运用同步机制 则有可能造成程序的死锁 经常表现为程序的停顿 或者不再响应用户的请求 Thread 1 prio 5tid 0 x00acc490nid 0 xe50waitingformonitorentry 0 x02d3f000 0 x02d3fd68 atdeadlockthreads TestThread run TestThread java 31 waitingtolock ajava lang Object locked ajava lang Object Thread 0 prio 5tid 0 x00accdb0nid 0 xdecwaitingformonitorentry 0 x02cff000 0 x02cff9e8 atdeadlockthreads TestThread run TestThread java 31 waitingtolock ajava lang Object locked ajava lang Object 31 案例分析 线程热锁 热锁 也往往是导致系统性能瓶颈的主要因素 其表现特征为 由于多个线程对临界区 或者锁的竞争 从整体的性能指标看 由于线程热锁的存在 程序的响应时间会变长 吞吐量会降低可能出现 频繁的线程的上下文切换 从操作系统对线程的调度来看 当线程在等待资源而阻塞的时候 操作系统会将之切换出来 放到等待的队列 当线程获得资源之后 调度算法会将这个线程切换进去 放到执行队列中 大量的系统调用 因为线程的上下文切换 以及热锁的竞争 或者临界区的频繁的进出 都可能导致大量的系统调用 大部分CPU开销用在 系统态 线程上下文切换 和系统调用 都会导致CPU在 系统态 运行 换而言之 虽然系统很忙碌 但是CPU用在 用户态 的比例较小 应用程序得不到充分的CPU资源 随着CPU数目的增多 系统的性能反而下降 因为CPU数目多 同时运行的线程就越多 可能就会造成更频繁的线程上下文切换和系统态的CPU开销 从而导致更糟糕的性能 32 应用服务器性能调优的定义 是指在既定的环境下 硬件确定 应用软件确定 对系统的应用服务器部分的各类参数进行调整 以达到能对更多的请求x响应 响应时间缩短 应用服务器运行更为平稳的目的 33 前提 硬件配置确定 无法针对各种设备和配置提供统一的最佳配置 甚至应用不同 硬件配置相同时也可能会有较大差别应用程序相对成熟 不会因为应用程序不太成熟 导致当压力上去时 出现大量未考虑并发的业务出错 或者某个地方的串行化处理 导致整个系统等待 这类问题无法避免 但是应用还是应该相对成熟时才能进行性能测试 34 目的 性能表现不理想 某些业务操作需要消耗过多的系统资源 CPU Memory 导致 系统宕机解决方案 对应用服务器 数据库服务器 操作系统进行调整 经验 一个应用系统的宕机 90 以上是应用自身存在问题聚焦 需要对应用系统进行分析 试图找出问题所在 35 关键 关键 快速的定位系统性能瓶颈与问题所在虽然可以针对机器配置和应用作出大致的判断 对应用服务器的各种参数进行调整 但是真正对系统进行调优 使之达到在当前硬件条件下的最好表现 还必须准确的定位瓶颈需要有相对能满足应用的配置尽量使各种资源能够隔离 以利于判断问题所在合理的人员配置 如操作系统 数据库 应用服务器的专业人员 36 方法 丰富的经验JDKMonitoringandManagementToolsJconsole JavaMonitoringandManagementConsole JMX compliantgraphicaltoolformonitoringaJavavirtualmachine ItcanmonitorbothlocalandremoteJVMs Jps JVMProcessStatusTool ListsinstrumentedHotSpotJavavirtualmachinesonatargetsystem Jstat JVMStatisticsMonitoringTool AttachestoaninstrumentedHotSpotJavavirtualmachineandcollectsandlogsperformancestatisticsasspecifiedbythecommandlineoptions Jstatd JVMjstatDaemon LaunchesanRMIserverapplicationthatmonitorsforthecreationandterminationofinstrumentedHotSpotJavavirtualmachinesandprovidesainterfacetoallowremotemonitoringtoolstoattachtoJavavirtualmachinesrunningonthelocalsystem 良好的工具支持 37 JDKTools Jconsole 38 JDKTools Jconsole JCONSOLE如何连接到ApusicJMXURL service jmx iiop jndi corbaname 1 2 hostname 6888 jmx rmi RMIConnectorServer用户 默认 admin密码 默认 admin注意 hostname 6888根据目标服务器所在的地址及端口进行填写 常见性能问题影响J2EE系统性能的可能因素JVM介绍线程介绍应用服务器性能调优简介金蝶Apusic性能调优Http服务性能调优数据库连接池性能调优线程池性能调优工具使用说明案例分析定位系统性能瓶颈 40 J2EE系统性能 系统调用栈可能的分析辅助工具EclipseTPTPJconsoleApusicAdminConsoleTHREADDUMPJVMHEAPDUMP Application Middleware JVM 41 J2EE系统性能测试工具 LoadRunnerRationalTestManagerRationalPerformanceTesterApacheJmeterGrinderApacheAB 42 性能测试的一般问题 测试脚本日志及日志文件JDBCDriver及连接池HTTP池应用异常 43 主健冲突 Causedby com microsoft jdbc base BaseBatchUpdateException Microsoft SQLServer2000DriverforJDBC SQLServer 违反了PRIMARYKEY约束 PK busi flow all 不能在对象 busi flow all 中插入重复键 2007 05 1715 35 13信息 con out 一个主健冲突的实例 privateStringgetNewAppId throwsHibernateException StringAppid 1000000000 StringSql selectmax b oriAppId fromAppBaseinfobwherelen b oriAppId 10 Queryquery session createQuery Sql returnAppid 表并未被锁定 在更新完成前被并发访问 导致取数重复 44 数据库死锁 录入机构人员信息录入机构分场所信息选取领域类别列表信息提交申请 busi user op 表锁 app baseinfo 表锁 log info 表锁 app suborg 表锁 busi user op 表锁 log info 表锁 app op scope 表锁 busi user op 行锁 log info 表锁 死锁 45 内存泄露 Vectorv newVector 10 for inti 1 i 100 i Objecto newObject v add o o null 发生内存泄露 Vector仍然引用该对象 所以这个对象对GC来说是不可回收的 46 提升性能的常规手段 更换JDBC驱动及使用优化的参数调整池设置策略启用Cache优化应用 47 Http服务性能调优 Http线程池性能调优 WebService的线程池配置应当将MaxSpareThreads和MaxThreads这两个属性的值设为一致 以避免频繁的线程创建和销毁 另外 在进行高强度压力测试时可以把Muxer的Backlog调高一点 至少达到500 48 Http服务性能调优 Httpservice部分参数调整 49 Http服务性能调优 Https请求的性能调优 由于Https的Muxer分发部分处理机制不太相同 不能用NIO机制 所以Https的性能参数设定除了调整Http线程池外 同时还会用到Muxer线程池 建议Muxhandle线程池的参数和Http线程池的参数相同 50 Http服务性能调优 Session存储部分性能调优 对session管理的性能调整 服务com apusic servlet http session SessionStoreService用于保存session数据 SessionStoreService本身是一个抽象类 有下列三种实现可供选择FileSessionStoreService使用数据文件保存session数据DBSessionStoreService使用BerkeleyDB保存session数据 当有大量Session存储时 效率极高 SQLSessionStoreSErvice使用RDBMS保存session数据 51 Http服务性能调优 其它调优 当传输量大时 如图片 使用压缩方式传输数据 在Servelet的Filter使用一些第三方的压缩库 这个需要浏览器支持 52 数据库连接池性能调优 53 线程池性能调优 可以单独配置各个服务所使用的线程池 线程池服务为com apusic util ThreadPoolService 用到线程池的服务有Muxer WebService JMSServer 如果没有为某个特定服务配置线程池 则使用默认的公共线程池 即名为apusic service ThreadPool name default的线程池 属性配置和前面描述的Http线程池一致 54 JVM参数的调优目标 由于Apusic运行在Java平台之上 VM的性能直接影响整个服务器的性能 VM运行的目标 JVM的的FullGC和YoungGC的比例应该适当 例如30秒到一分钟作一次FullGC 中间的GC应该为YoungGC 使系统额外开销尽量小 不同的机器配置 不同的JDK有不同的参数配置 总的目标是满足上一步的原则 55 JVM参数的调优目标 56 操作系统的调优 介绍相关内容 网络参数的调优文件打开数量限制的调整文件IO的数量是否明显异常系统的Cpu开销尽量小 User的Cpu开销比例尽量高和其它应用服务器比较时 是否各项资源调用大致相同 例如 网络吞吐量 文件打开数 cpu开销是否平稳 57 性能调优的关键 发现瓶颈 虽然可以针对机器配置和应用作出大致的判断 对应用服务器的各种参数进行调整 但是真正对系统进行调优 使之达到在当前硬件条件下的最好表现 还必须准确的定位瓶颈需要有相对能满足应用的配置尽量使各种资源能够隔离 以利于判断问题所在各种系统跟踪工具合理的人员配置 如操作系统 数据库 应用服务器的专业人员 58 应用程序对性能的影响 synchronized关键词的滥用 synchronized是指 避免不同的线程同时进入被同一把锁锁住的方法体内例子 publicsynchronizedintsubmitApplyNew 在jsp页面中 是这样使用RequistionBase对象的 分析 jsp每执行一遍 RequistionBase对象就被重新new一个新的实例 假设线程T1和线程T2分别访问同一个页面 此页面new了两个RequistionBase对象 T1获得了RequistionBase的一个实例的锁 而T2获得了RequistionBase另一个实例的锁 由于是两把锁 T1和T2可以同时访问submitApplyNew方法 核心问题 根本不需要synchronized关键字 不应该试图通过java的锁来解决数据库的并发问题 而应该通过数据库的锁机制完成 常见性能问题影响J2EE系统性能的可能因素JVM介绍线程介绍应用服务器性能调优简介金蝶Apusic性能调优Http服务性能调优数据库连接池性能调优线程池性能调优工具使用说明案例分析定位系统性能瓶颈 60 如何对基于Apusic的应用进行分析 如何对基于Apusic应用服务器之上的客户应用进行分析 需要非常熟悉Apusic应用服务器需要辅以良好的工具支持 ApusicStudio 61 ApusicStudio使用过程简述 打开概要分析对话框 62 新建启动配置项 监控类型 ApusicStudio使用过程简述 续 63 设置监控类型 ApusicStudio使用过程简述 续 64 设置过滤项 include exclude ApusicStudio使用过程简述 续 65 为避免乱码 可设置环境变量 Duser language en ApusicStudio使用过程简述 续 66 点击 概要分析 启动服务器开始监控运行测试案例 收集数据对收集的数据进行分析 ApusicStudio使用过程简述 续 应用服务器性能调优简介金蝶Apusic性能调优影响J2EE系统性能的可能因素Http服务性能调优数据库连接池性能调优线程池性能调优工具使用说明案例分析定位系统性能瓶颈 68 案例 定位性能瓶颈 案例描述 publicclassSmartBean publicvoiddoSmartJob System out println dosmartjob publicclassLazyBean publicvoiddoLazyJob System out println dolazyjob try dosomehardjobThread sleep 5000L catch Exceptione e printStackTrace 69 案例描述 在jsp中调用上述两个JavaBean performanceInvokeSmartBeanandLazyBean 案例 定位性能瓶颈 70 现象 LazyBean的doLazyJob方法是整个系统的性能瓶颈问题 如何快速定位到此方法 解决方案 使用ApusicStudio的方法执行时间统计工具 案例 定位性能瓶颈 71 案例 定位性能瓶颈 关键点 72 案例 定位性能瓶颈 结果 73 回顾 故障产生不是今天才产生的排除故障的核心是问题定位问题定位的核心是现场证据性能优化 系统调忧是一个系统性工程 谢谢