Download as PDF, PPTX
![网络限制
• 如果网络达到饱和，则它就会成为瓶颈
• 可以监视网络来确定网络性能，解决性能问题时，不要忘记检查
数据包丢失或错误
• 数据包再发送、重复数据包、数据包监听丢失
• netstat (显示协议统计和当前的 TCP/IP 网络连接 )
• netstat [-a] [-e] [-n] [-s] [-p protocol] [-r] [interval]
• 网络可能会在带宽使用率低于50%时达到饱和
• 应该确保应用系统有足够的带宽
• 如客户端到WLS，WLS到数据库服务器之间的带宽。
• 在集群中
• Servlets和EJBs复制会话信息需要更大的网络带宽
• 可能的解决方案：
• 购买更多带宽
• 使用更大的数据包，从而更好的利用网络带宽
• 使用特定于操作系统的配置](https://image.slidesharecdn.com/05-wls-101118194440-phpapp01/75/05-wls-16-2048.jpg)
![调整垃圾回收常见参数（续）
• 堆中代的大小
• -XX:NewSize=[n]
• -XX:MaxNewSize=[n]
• 建议在生产系统中将NewSize和MaxNewSize设置为相同值
• 建议值为最大堆大小的四分之一左右
• 不要超过堆大小的二分之一
• 年轻代中年轻代空间的大小
• -XX:NewRatio=[n] 年老代:年轻代的比例
• HotSpot客户端默认为8，服务器端默认为2
• 年轻代空间:存活空间比率
• -XX:SurvivorRatio=[n]
• 默认值是25，建议设置为4～8
• 从年轻代提升到年老代的阈值
• -XX:MaxTenuringThreshold=[n]](https://image.slidesharecdn.com/05-wls-101118194440-phpapp01/75/05-wls-32-2048.jpg)
Uploaded byMeng He
05.wls调优
本文件讨论了wls（WebLogic Server）的性能调优，涵盖了调优的准备工作、JVM调整、核心参数和Java EE相关调整。强调了性能工程的重要性、性能测量的标准，以及在软件开发过程中如何保持高效的系统性能。还详细介绍了识别和解决性能瓶颈的方法，包括CPU、I/O和网络限制等。
05.wls调优
- 1.
- 2. 议程 • 性能调优概述 • 调优准备工作 •WLS的JVM 调整 • WLS的核心参数调整 • WLS的Java EE相关调整
- 3. 议程 • 性能调优概述 • 调优准备工作 •WLS的JVM 调整 • WLS的核心参数调整 • WLS的Java EE相关调整
- 4.
- 5. 性能 • 性能差的代价： • 高成本与应用程序性能差有关 •IT的投资回报 • 给组织收入流带来风险 • 客户满意度 那么，什么是性能？ 在哪些情况下应开始考虑性能？ 如何提高性能？
- 6. 软件性能工程 • 软件性能工程（Software PerformanceEngineering， SPE）是一种构建软件系统以达到系统性能目标的方 法。 • SPE过程开始于开发周期早期的系统需求分析阶段。 • 环境所需要的性能目标被记录下来 • 然后，在整个设计和实施阶段，使用定量方法来确定 符合要求的架构。 • 这些方法可用于排除那些性能可能难以接受的架构。 • SPE存在于整个开发过程中，其目的包括： • 预测和管理不断发展的软件的性能 • 依据规范监视实际性能，并报告确定的问题
- 7. 性能测试 • 测试性能时，应该让系统运行较长时间，例如一天或 一周，以生成较长时段的趋势 • 一些注意事项： •缺少实际网络连接的测试会产生错误的测量结果 • 模拟的用户少会显著不同于模拟的用户多时的状况 • 网络吞吐量可能会大于部署的环境 • 非持久性消息的性能与处理器和内存有关 • 磁盘速度对持久性消息至关重要
- 8. 性能的衡量标准及关注点 • 软件系统的性能通常使用如下度量来衡量： • 响应时间– 时间度量。例如，服务器传递网页所花费的请求响 应时间。 • 吞吐量 – 速率度量（单位时间的请求数）；例如，每秒请求数 、每秒比特数。 • 资源利用率 – 使用量度量。例如，CPU使用率 • 可伸缩性是指在以下因素有所增加的情况下，系统在 规范范围内的执行能力： • 用户负载 • 数据负载 • 硬件扩展
- 9. 测试结果集 • 每个基准测试结果集应（至少）包括以下详细信息： • 应用程序的版本和设计 •WLS的版本和Service Pack • 硬件配置 • 操作系统配置 • WLS域和集群的配置 • …… • 结果报告 • 平均响应时间 • 客户端负载 • 评价吞吐量 • ……
- 10.
- 11. 议程 • 性能调优概述 • 调优准备工作 •WLS的JVM 调整 • WLS的核心参数调整 • WLS的Java EE相关调整
- 12. 调优的具体操作思路及更改WLS属性 • 必须隔离潜在的瓶颈才能确定WLS是不是问题所在 • 更改属性的步骤： •创建可重复的合适测试 • 测量基准性能 • 修改单个WLS的属性 • 如果合适，重启服务器 • 重新测量性能
- 13. 找到瓶颈 — CPU限制 •很容易检查到CPU限制情况，因为此时CPU会以100% 或接近100%的使用率运行 • 可能的原因包括： • 垃圾回收 • Java应用程序本身效率问题 • 解决方法： • 监视垃圾收集 • 分析Java应用程序
- 14. 找到瓶颈 — I/O限制 •I/O限制通常具有以下特征： • CPU未达到饱和 • 不管客户端负载如何，性能都相同（例如，无论有多少个客户 端，到数据库的TPS始终为50个） • I/O限制常见的类型： • 数据库限制 • 网络限制
- 15. 数据库限制 • 应用程序性能的瓶颈可能是在数据库访问环节 • 配置解决方法： •使用索引 • 允许多个数据库连接 • 使用快速的专用计算机 • 微调数据库 • ……
- 16. 网络限制 • 如果网络达到饱和，则它就会成为瓶颈 • 可以监视网络来确定网络性能，解决性能问题时，不要忘记检查 数据包丢失或错误 •数据包再发送、重复数据包、数据包监听丢失 • netstat (显示协议统计和当前的 TCP/IP 网络连接 ) • netstat [-a] [-e] [-n] [-s] [-p protocol] [-r] [interval] • 网络可能会在带宽使用率低于50%时达到饱和 • 应该确保应用系统有足够的带宽 • 如客户端到WLS，WLS到数据库服务器之间的带宽。 • 在集群中 • Servlets和EJBs复制会话信息需要更大的网络带宽 • 可能的解决方案： • 购买更多带宽 • 使用更大的数据包，从而更好的利用网络带宽 • 使用特定于操作系统的配置
- 17. OS限制 • 每种操作系统缺少的优化参数是不同的 • 在Windows平台，缺省的设置通常就足够了 •在UNIX和Linux通常需要进行适当的调整 • UNIX和Linux通常需要调整以下一些参数设置 • 文件描述符 • Time wait interval • Swap空间 • 进程和线程
- 18.
- 19. Time Wait Interval •应用程序关闭的TCP连接，在被操作系统释放前，将先进入等待 状态。套接字处于等待状态的时间称为time wait interval。在这种 状态下，操作系统会维护分配给该socket的资源，包括文件描述 符 • 这个参数决定TCP Socket 在被执行关闭操作后保持alive状态的时 间间隔
- 20. swap空间 • 太多的Swap空间 • 会浪费磁盘空间 •太少的Swap空间 • 则系统会发生错误 • 如果Swap空间用完 • 则服务进程无法启动，通常会出现“application is out of memory‖的错误，严 重时会造成服务进程的死锁。 • Swap分区的数量对性能也有很大的影响
- 21. 议程 • 性能调优概述 • 调优准备工作 •WLS的JVM 调整 • WLS的核心参数调整 • WLS的Java EE相关调整
- 22. Java虚拟机 • 是在实际计算机（硬件）上以软件形式实现的抽象计 算机 • 读取独立于平台的编译字节码 •其设计目的是支持Java编程语言 • 通常是针对本地操作系统编写的
- 23. Java堆（Heap） • 动态分配块的内存区域称为堆 • JVM堆存储正在执行的Java程序创建的所有对象 •任何由根引用的对象都是可访问的，因此是活动对象 • 本地变量驻留在Java堆栈上，每个执行线程都有自己 的堆栈
- 24. 垃圾回收（Garbage Collection） • 此过程确认如何检测不再引用的对象，以及如何使未 使用的内存可用于将来分配 •由JVM自动执行，因此程序员无需显式释放对象 • 垃圾包括任何程序都无法引用的对象 • 没有任何静态、实例或本地变量直接或间接引用它们
- 25. JVM调整 • Java EE应用程序部署在JavaEE应用服务器上 • 作为Java程序，Java EE应用服务器需要Java虚拟机来 运行和支持其上运行的Java应用程序 • 正确配置JVM参数可以增强应用服务器的性能 • JVM调整的内容包括： • 内存参数（堆大小） • 垃圾回收 • 堆栈大小 • 类加载 • 编译/解释
- 26. JVM实现与版本选择 • 不同的供应商针对不同的硬件平台提供不同的JVM实 现 • HotSpotVM • JRockit JVM • IBM JVM • HP JVM • 推荐使用经过WLS认证的Java虚拟机 • 在IA架构的系统上应考虑使用JRockit
- 27. HotSpot VM • 与其他VM一样，HotSpotVM首先直接解释应用程序的 字节码 • 然后，检测占用应用程序大部分时间的方法（“热点 ”），并将这些方法转换为本地代码 • HotSpot VM使用自适应优化技术 • 它包括两个可互换的版本： • 客户端：调整侧重于快速加载和编译重要类和方法 • 服务器端：加载速度较慢，但更侧重于生成高度优化的JIT编译 ，从而获得更高的性能
- 28. 分代垃圾回收 • 按“代”管理堆内存，“代”用于存放生存权不同的 对象 • 根据详细研究得出的结论，多数服务器端堆对象的生 存期都很短。而有些对象的生存期却较长 •分代垃圾回收利用这类生存期短的对象来提高垃圾回 收的实时性能 • 分代垃圾回收是对传统垃圾回收算法的重大改进
- 29. 分代堆概述 • 堆大致可分为三个区域： • 年轻代 •年老代 • 持久代 • 年轻代可进一步分为： • Eden • 存活空间（2个）
- 30. Hotspot JVM的监视工具 • 在5.0版本中，对Java虚拟机（JVM）配备了很多用于监 视和管理的工具，包括： •jconsole: 符合JMX标准的JVM监视和管理控制台 • jps: JVM进程状态工具 • jstat: JVM性能和GC统计信息监视工具 • jinfo: 输出JVM配置信息的工具 • jmap: 输出堆和共享对象内存映射的工具 • jstack: 线程堆栈跟踪信息输出工具
- 31. 调整垃圾回收常见参数 堆大小及持久代大小 • 使用-Xms和-Xmx控制堆的原始值（最小值）和最大值 • 如:java –Xms128m –Xmx128m • 建议在生产系统中将Xms和Xmx设置为相同值 • -XX:+AggressiveHeap • 检查计算机资源（内存大小和处理器数量），并且尝试将各种 参数设置为最合适长时间运行的值 • 持久代保留给JVM存入类和方法的反射对象,默认大小 为4M。可使用 • -XX:PermSize标志设置初始值。 • -XX:MaxPermSize用来指定持久代大小的上限
- 32. 调整垃圾回收常见参数（续） • 堆中代的大小 • -XX:NewSize=[n] •-XX:MaxNewSize=[n] • 建议在生产系统中将NewSize和MaxNewSize设置为相同值 • 建议值为最大堆大小的四分之一左右 • 不要超过堆大小的二分之一 • 年轻代中年轻代空间的大小 • -XX:NewRatio=[n] 年老代:年轻代的比例 • HotSpot客户端默认为8，服务器端默认为2 • 年轻代空间:存活空间比率 • -XX:SurvivorRatio=[n] • 默认值是25，建议设置为4～8 • 从年轻代提升到年老代的阈值 • -XX:MaxTenuringThreshold=[n]
- 33. 调整垃圾回收常见参数（续） 开关设置参数 • 垃圾回收开关设置 • -XX:+DisableExplicitGC禁止显式垃圾回收 • -XX:+UsePerfData 此标志将启用对JVM VisualGC监视 • -verbosegc 详细列出垃圾回收信息 • -XX:+PrintGCDetails 输出有关垃圾回收的其它信息 • -XX:+PrintGCTimeStamps 输出每次垃圾回收开始时的时间戳 • 建议的观察效果 最短垃圾回收间隔应该大于10 秒 完全垃圾回收的间隔应该大于10分钟
- 34.
- 35. 垃圾回收算法 选项 说明 代 -XX:+UseParallelGC并行/吞吐量垃圾回收 年轻代 -XX:+UseConMarkSweepGC 并发型低暂停垃圾回收 年老代 -XX:+UseTrainGC 增量型/自适应型低暂停垃 圾回收 年老代 default 串行垃圾回收—让应用程 序暂停 年轻代和年 老代 • 影响垃圾回收算法的 HotSpot命令行开关项
- 36. Ergonomics（人机工效性） • 一种从JDK 1.5新增的字调整功能，在JavaSE 6中得 到显著增强 • 有了人机工效性的功能，只需要做极少量的命令行调 整，便能获得良好的性能 • 该功能引入了一种称为“基于行为的调整”的新调整 策略 • 只要指定一种所需行为（而无需设置各种参数），即 可调整垃圾收集。 • 可将所需行为设置为下列行为之一： • 最长暂停时间目标 • 应用程序吞吐量目标
- 37. 最长暂停时间目标 • 所谓暂停时间，就是垃圾回收通过停止应用程序来恢 复不再使用的堆空间所用的时间 • 通过设置此目标，可以限制此类应用程序暂停的最长 时间 •使用以下命令行标志指定： • -XX:MaxGCPauseMillis=nnn • 如果指定了此目标，垃圾回收会调整堆大小和其他参 数，使暂停时间始终比指定时间短
- 38. 吞吐量目标 • 设置吞吐量目标时，可指定垃圾回收可以耗费的总垃 圾回收时间 • 使用以下命令行标志指定： •-XX:GCTimeRatio=nnn • 垃圾回收时间与应用程序时间之比为1/（1+nnn） • 衡量吞吐量目标时，会考虑堆垃圾回收时间以及非垃 圾回收时间（又称应用程序时间）
- 39. 内存占用目标 • 在满足设置的吞吐量和最长暂停时间目标的同时， JVM会尝试减少总的内存占用量 • 垃圾回收将持续减小堆的大小，并检查能否达到最长 暂停时间目标和吞吐量目标 •一旦发现未达到某个目标，垃圾回收会再次努力达到 该目标 • 因为，最终JVM的总内存占用量也会减少
- 40. 人机工效性行为 • 为了满足命令行标志定义的吞吐量目标，垃圾回收将 自动调整堆的大小 • 在以下过程中，堆的大小会来回调整： •JVM初始化 • WLS的行为发生变化 • 为了达到吞吐量目标，通常会使用较大的堆 • 为了达到最长暂停时间目标，并尽量减少内存占用， 通常会使用较小的堆。
- 41. 虚拟机启动模式 • 在J2SE 5.0中，如果某台计算机配置了两个或更多个 CPU，以及2GB或更大的物理内存，则被认为是 “Server” •在JVM启动过程中，，如果没有指定是-server，也没 有指定为-client，会检测应用程序/服务器是否在 “Server”上运行，如果是，就使用Hotspot的server 模式
- 42. 关于人机工效性的其他信息 • 在“server”上，默认的垃圾回收是并行垃圾回收算法 • 默认情况下，将使用-XX:+UseAdaptiveSizePolicy实现 并行垃圾回收 •默认情况下，初始堆大小是以下两者中的较大者： • 计算机物理内存的1/64 • 或要启动的应用所需要的最小大小 • 默认情况下，最大的堆大小是以下两者中的较小者： • 物理内存的1/4 • 或1GB
- 43. 关于人机工效性的其他信息 • 在启动JVM时，也可在命令行下定义多个目标 • 如果同时存在多个目标，将遵从如下优先顺序满足各 个目标： •最长暂停时间目标 • 吞吐量目标 • 最小内存占用目标
- 44. JRockit VM • JRockitVM是针对Intel和Solaris（SPARC）架构开发 和优化的，以便确保Java应用程序的可靠性、可伸缩 性和可管理性 • JRockit VM专用于服务器端应用程序 • 为了获得更好的运行时性能，JRockit使用JIT编译将 Java代码编译为本地代码 • JRockit 在后台对大量使用的方法进行优化，这些方法 是使用低成本取样检测到的 • JRockit还附带一组独立的管理和监视工具（ JRockit Mission Control）
- 45. JRockit的分代垃圾收集 • JRockit中两种垃圾回收类型： • 双代垃圾回收，堆被分为两个代 •年轻代（Nursery） • 年老代 • 单代垃圾回收，所有对象都被分配到堆中的一个空间内
- 46. JRockit调优思路 • 基本参数调整 • 调整Heap大小 •调整垃圾回收算法 • 调整Nursery大小 • 调整暂停时间目标 • 性能调整 • Lazy Unlocking • Call Profiling • Large Pages • 高级参数调整 • 调整压缩比 • 调整TLA大小
- 47. JRockit基本参数调整 • 调整Heap大小 • -Xms:<size> •-Xmx:<size> • 例如，java -Xms:512m -Xmx:1024m MyServerApp • 调整垃圾回收算法 • -XgcPrio:throughput • -XgcPrio:pausetime • -XgcPrio:deterministic • 例如，java -XgcPrio:pauseTime MyTransactionApp
- 48. JRockit基本参数调整（续） • 调整Nursery大小 • -Xns:<size> •例如，java -Xms:512m -Xmx:1024m -XgcPrio:pausetime - Xns:128m MyTransactionApp • 调整暂停时间目标 • -XpauseTarget:<time> • 例如，java -XgcPrio:pausetime -XpauseTarget:250 MyTransactionApp
- 49. JRockit性能调整 • Lazy Unlocking •-XXlazyUnlocking ，减少同步方法的竞争 • Call Profiling • -XXcallProfiling， 针对用户代码做统计优化 • Large Pages • -XlargePages， 优化TLB执行方式，CPU的地址映射
- 50. JRockit高级参数调整 • 调整压缩比 • -XXcompactRatio:<percentage>，表示每次垃圾回收时进行压 缩的对象比例，一般为1～20 •-XXcompactSetLimit:<references>，表示当对某个对象的引用 超过配置值时，停止压缩 • 调整TLA（Thread Local Area ） • -XXtlaSize:min=<size>,preferred=<size>，建议preferred为最 大的常用对象大小的二倍，在多线程并且局部对象比较大时有 效
- 51. JRockit Mission Control •JRockit Mission Control包括一组独立的管理和监视工 具： • JRockit 管理控制台 • 符合JMX标准的监视工具 • JRockit运行时分析器（Runtime Analyzer） • 记录JVM和运行中的应用程序，并帮助您对其进行分析 • JRockit内存泄漏检测器 • 检测和查找导致内存泄漏的原因 • JRockit Mission Control的主要功能是执行必要的监控 ，同时尽量减少对系统的影响
- 52. JRockit Mission Control- Architecture
- 53. 管理服务器 • 默认情况下，JRockit VM中的管理服务器处于禁用状态 •要启用管理服务器，请在JVM启动脚本中添加以下命令行 参数： • - Java –Xmanagement … weblogic.Server • 管理服务器用于连接的默认端口是7091 • 通过设置以下命令行参数，可以更改管理服务器端口： • -Djrockit.managementserver.port=<port> …
- 54.
- 55. 最佳实践 • 不建议在运行WLS（JRockit JVM）的同一台计算机上 运行JRockit管理控制台 •为防止GUI占用WLS的资源，建议远程运行JRockit管 理控制台 • 为防止未经授权访问JRockit管理服务器，应在防火墙 中阻塞管理服务器使用的端口（例如，7091）
- 56. • 不要使用 System.gc()，因为这是个Full GC，中断时 间会比较长，效率低。也不要使用 finalize() 方法。 • Object 不需要时，显示的将其赋值为 null • 多用 Pool，但是小的 Object 不要使用 pool，因为会带 来 GC 的效率问题 程序设计与GC的最佳实践
- 57. JVM/CPU比率 Rule of Thumb 2-4CPUs per WebLogic JVM Establish Repeatable Benchmarks and Validate for Your Application!!! Empirical experiences on different platforms and applications show that optimal performance can vary from 1 CPU to 8 CPU’s per JVM
- 58. 议程 • 性能调优概述 • 调优准备工作 •WLS的JVM 调整 • WLS的核心参数调整 • WLS的Java EE相关调整
- 59.
- 60. 本地IO性能包（续） • 默认情况下，本地性能包处于启用状态 • 性能包与平台相关 •此外，也可以在config.xml中启用本地IO
- 61. Socket Readers • 两种socketreaders类型: • Native:性能更好 • Pure Java: 性能相对差，跨平台 • 如果所使用的平台没有可利用的性能包，WLS就分配 一定比例的执行线程用于”Socket Readers”，如果 应用程序经常使用I/O,可以通过提高这个比例来获得性 能的提高。 • Default value: 33% • Minimum value: 1% • Maximum value: 99%
- 62.
- 63. Socket Readers（续） • 设置Socketreader的命令行参数是： • -Dweblogic.ThreadPoolPercentSocketReaders=value • 也可以在config.xml中进行设置
- 64. 阻塞线程 • 每个客户端请求都将使用某个执行队列中的一个线程 • 有些操作（例如，数据库调用、应用程序中的计算循 环）会陷入无限循环 •这会导致相关线程因该操作而被阻塞，直到该操作完 成为止 • 如果有许多这样的线程被阻塞，服务器的性能就会大 幅降低
- 65. 阻塞线程（续） • 服务器可以根据某些特定的阈值来识别此类情况，并将 服务器的状态标记为Failed • 这些阈值包括： •Max stuck Thread （阻塞线程最长时间） • Stuck Thread Timer Interval （阻塞线程计时器间隔）
- 66. 阻塞线程（续） • 其他的阈值包括： • MaxStuck Thread Time（阻塞线程最长时间） • Stuck Thread Count（阻塞线程计数） • Failure Action（故障操作）
- 67.
- 68. 垃圾回收阈值 • 内存低会严重影响服务器的性能 • 内存低情况会触发一些开销很高的任务，如“分页” 和“垃圾回收” •堆管理员来说，预先了解此类情况以防止严重的 OutOfMemory（内存不足）情况发生是非常重要的
- 69. 垃圾回收阈值（续） • 服务器可以根据某些特定的阈值来识别此类情况，并 将服务器的状态标记为WARNING • 包括的阈值有： •Low Memory GCThreshold （判断内存低的GC阈值） • Low Memory Granularity Level （判断内存低的粒度级别） • Low Memory Sample Size（判断内存低的样例大小） • Low Memory Time Interval（判断内存低的时间间隔）
- 70. 块（Chunk）调整 • 块（Chunk）是用于I/O的临时缓冲区 • WebLogicJVM将网络数据划分为块 • 默认的块大小为 4080 字节 (4KB) • 针对频繁使用网络的应用程序，应该调整块大小 • 调整块大小还可以减少socket读写次数 • 用于设置块大小的命令行属性是： • -Dweblogic.Chunksize=n (n = chunk size)
- 71. 调整块（Chunk）大小 • 如果应用负载通常为小数据量内容，将块值设置为较 小的值 • 反之亦然，为大负载设置大的块值 •在JVM的客户端和服务器端都设置块值会带来更好的 性能 • 设置块值时，需要与网络MTU值、OS的内存页面大小 相匹配，这样能带来更好性能 • 确保块大小是8的整数倍 • 确保块大小是MTU大小的整数倍
- 72. 调整块（Chunk）缓冲池 • WLS在内部创建缓存块（Chunk）的池，实现块重用 • 块（Chunk）被缓存，可以减少创建块的开销 •设置块池大小的命令行属性为: • -Dweblogic.utils.io.thunkpoolsize=n • 缺省的块池大小为512 • 根据负载需要的块缓存和并发用户的活动行为来设置 块池的大小 • 当并发用户较大时，设置较大的块池
- 73. AcceptBacklog（连接积压缓冲） • WLS使用AcceptBacklog属性 • 决定在等待队列中最多可以有多少TCP连接等待处理 •如在许多客户端连接被拒绝，而服务器端没错误显示 • 说明AcceptBacklog值设得过低 • 如果连接时频繁收到“connection refused‖消息 • 可以适当增大acceptBacklog的值，每次增加25％ • AcceptBacklog值过高会给服务器带来太大开销
- 74. AcceptBacklog（续） • 配置参数: • 默认值为50 •最小值：0 • 最大值：取决于操作系统
- 75.
- 76. 线程 • 线程是程序的执行路径 • 线程采用各种编程语言来提高性能和增强功能 •线程包括两种类型： • 本地线程 • 使用操作系统的本地功能来管理多线程进程 • 绿色线程 • 模拟多线程环境，不依赖任何本地操作系统功能
- 77. WLS 9.x 之前版本中的线程管理 •手段调整线程池大小 • 使用多个执行队列来分散工作 • 使用以下参数调整执行队列： • 线程计数 • 队列长度 • 阈值百分比 • 最大线程数 • 线程优先级
- 78. 工作管理器（Work Managers） • WLS9.x 之后的版本拥有自调优功能，也就是说，默 认情况下，它可以根据需要调整线程的大小 • WLS 还为管理员提供了Work Manager的Hook API， 用于调整线程 • WLS可以根据以下因素确定工作的优先级： • 管理员定义的参数 • 运行时度量 • 执行一个请求所用的实际时间 • 请求进出线程池的速率 • 调整工作管理器可以显著调高应用程序的性能
- 79. Oracle Confidential. |79 为何要对工作任务划分? • 应用程序之间的公平共享 • 避免死锁 • 工作任务严格有序的被处理 • 为特定的工作任务类型设置优先级 • 过载保护 传统方法 多线程池 工作管理器（Work Managers） 工作划分
- 80. Oracle Confidential. |80 工作管理器（Work Managers） WLS的自调优线程池 Network Socket Handlers (―Muxers‖) Asynchronously dispatched work from WebLogic kernel, subsystem, or application Request Queue Self Tuning Thread Pool 1. Monitor rate of request processing 2. Adjust thread pool size accordingly • Active • Standby • Stuck • Hogging
- 81. 默认工作管理器 • 所有应用程序都具有相同的优先级 • 将为每个应用程序分配默认的公平线程份额 •如果没有为应用程序显示分配工作管理器，此应用程 序将使用默认的工作管理器 • 可以通过创建和配置一个名为“default”的全局工作 管理器，来替换默认的工作管理器
- 82. Oracle Confidential. |82 • 请求类（Request Class）可以实现根据优先级安排工 作任务，其包括如下三种类型： • Fair Share • Response Time • Context based • 约束（Constraints）定义了分配给执行请求的最大线 程数和最小线程数，以及WLS开始拒绝后续请求之前 可以排队或执行的请求的总数，其类型包括： • Minimum threads • Maximum threads • Capacity 工作管理器（Work Managers） 工作任务划分
- 83. Oracle Confidential. |83 配置公平份额请求类 Fair Share Request Class • 公平份额请求类指定处理请求所需的线程使用时间的 评价百分比 • 配置选项：“Name”（名称）和“Fair Share”（公平份额） • 默认值：50 • 最小值：1 • 最大值：1000
- 84. Oracle Confidential. |84 配置响应时间请求类 Response Time Request Class • 响应时间请求类指定响应时间目标（以毫秒为单位） • 配置选项：“Name”（名称）和“Goal”（目标） • 默认值： 0
- 85. Oracle Confidential. |85 配置上下文请求类 Context Request Class • 上下文请求类根据上下文信息（例如，当前用户或当 前用户所属的组）为请求分配请求类 • 配置选项： “Name” （名称）和“Context Case”（上下文案例）
- 86. Oracle Confidential. |86 配置最大线程数约束 • 最大线程数约束限制了最多可以有多少个并发线程执 行受此约束制约的请求 • 配置选项： • Name（名称）: 用户指定的名称 • Count（计数）: 线程计数 (默认值: -1) • Data Source（数据源）: 其大小被当作最大约束的连接池的名 称
- 87. Oracle Confidential. |87 配置最小线程数约束 • 最小线程数约束保证服务器至少分配多少个并发线程 给受此约束制约的请求 • 配置选项 • Name（名称）: 用户指定的名称 • Count（计数）: 线程计数 (默认值: -1)
- 88. Oracle Confidential. |88 配置容量约束 • 容量约束会使服务器在达到其容量时，拒绝后续请求 以避免服务器死锁 • 配置选项: • Name（名称）: 用户指定的名称 • Count（计数）: 线程计数 (默认值: -1)
- 89. Oracle Confidential. |89 引用请求类型和约束 • 工作管理器（Work Manager ）是通过封装用于调度请 求的请求类和（或）约束来定义的 • 配置选项: • Name （名称） • Request Class/Constraint （请求类、约束）
- 90. Oracle Confidential. |90 全局工作管理器 (Global Work Managers) • 可供服务器上部署的所有应用程序和模块使用 • 可以从WLS管理控制台创建或在域的配置文件 config.xml中创建 • 创建单独的实例以区分来自其它应用程序的工作 • 可以在应用程序的部署描述符中使用调度策略引用相 应组件的名称，从而控制应用程序的性能 • 对所有应用程序使用相同的调度策略
- 91. Oracle Confidential. |91 通过config.xml配置全局工作管理器
- 92. Oracle Confidential. |92 通过管理控制台配置全局工作管理器 • 通过管理控制台创建Global Work Manager
- 93. Oracle Confidential. |93 通过管理控制台配置全局工作管理器组件 • 通过管理控制台创建Global Request Class
- 94. Oracle Confidential. |94 通过管理控制台配置全局工作管理器 • 将组件封装到Global Work Manager
- 95. Oracle Confidential. |95 配置应用级工作管理器 Application Level Work Manager • 应用程序范围的工作管理器仅可供特定的应用程序或 模块使用 • 应用程序调度策略: weblogic-application.xml
- 96. Oracle Confidential. |96 EJB组件级工作管理器 • 组件级工作管理器只能分配到相应的组件 • EJB调度策略： • Weblogic-ejb-jar.xml • 用法： • <weblogic-enterprise-bean> • <ejb-name>xxx</ejb-name> • <jndi-name>xxx</jndi-name> • <dispatch-policy>Work manager here</dispatch-policy> • <dispatch-policy>也可以表示自定义执行队列，以便向 后兼容
- 97. Oracle Confidential. |97 EJB组件级工作管理器示例
- 98. Oracle Confidential. |98 配置Web应用程序级的工作管理器 • Web应用程序范围的工作管理器仅可供特定的Web应 用程序使用 • Web应用程序调度策略: weblogic.xml
- 99. Oracle Confidential. |99 阻塞线程工作管理器 Shutdown Trigger • 配置阻塞线程工作管理器是为了根据相应的阻塞线程 参数设置来结束所有线程，从而关闭工作管理 • 能提供过载保护 • 配置选项： • 阻塞线程最长时间：在服务器将某个线程诊断为阻塞前，该线 程必须连续工作的秒杀 • 阻塞线程计数：使服务器转换到Failed状态的阻塞线程数
- 100. Oracle Confidential. |100 阻塞线程工作管理器（示例） Shutdown Trigger • 如下的示例，如果有5个线程被阻塞60秒以上，以下工作 管理器将关闭
- 101. Oracle Confidential. |101 向后兼容性 • 向后兼容执行队列 • 使用命令行选项： • -Dweblogic.Use81styleExecuteQueues=true • 在config.xml中更改服务器设置 • <Use81-style-Execute-Queues>true</Use81-style- Execute-Queues> • 以便于应用程序迁移，版本10中提供了向后兼容功能 • 已经配置的工作管理器在运行时会被服务器实例转换 为执行队列 • 执行队列的线程计数以约束中定义的值为基础 • 如果工作管理器未施加任何约束，则会使用全局默认 执行队列
- 102. Oracle Confidential. |102 了解CommonJ • CommonJ是BEA和IBM联合推出的Java EE应用程序 编程模型和API规范 • 提供了一种编程方式来处理应用程序中的工作 • CommonJ工作管理器提供了服务器级别的配置，用于 设置Servlet和EJB的调度策略
- 103. Oracle Confidential. |103 访问CommonJ工作管理器 • 可以直接在应用程序中使用JNDI查找访问CommonJ工 作管理器 • 这类工作管理器不需要使用调度策略 • Servlet和EJB可以在本地JVM中通过JNDI查找访问工 作管理器
- 104. Oracle Confidential. |104 将CommonJ映射到工作管理器 • 通过在相应的部署描述符中定义resource-ref，可以将工 作管理器资源与应用程序相关联 • Servlet引用web.xml中的resource-ref来访问工作管理器 • EJB引用ejb-jar.xml中的resource-ref来访问工作管理器 • CommonJ工作管理器通过使用服务器描述符中的同名元 素映射到WLS工作管理器
- 105. 议程 • 性能调优概述 • 调优准备工作 •WLS的JVM 调整 • WLS的核心参数调整 • WLS的Java EE相关调整
- 106. 如何优化J2EE应用程序？ • 在开发阶段作优化 • 构架和应用程序设计方面 •程序代码方面的优化 • 对应用程序作单元测试 • 发现应用程序存在的瓶颈 • 部署方面的优化 • OS/JVM/Application Server • 数据库、网络 • 作系统测试和基准测试 • 发现系统级存在的瓶颈
- 107. JSP预编译 • 预编译JSP可以节约服务器在执行（处理客户端请求） 时进行转换和编译的时间 • JSP预编译可以通过以下方式来完成： •手动使用WLS编译器，如weblogic.jspc或appc • 自动使用weblogic.xml中的precompile选项 • 如果weblogic.xml中的precompile选项处于ON，则每 次重新启动服务器以及在定位到其它服务器时，都将 重新编译JSP
- 108. 使用JSP编译器jspc • JSPServlet使用名为jspc的JSP编译器将JSP转换为 Servlet • 可以在命令行下调用jspc进行调试，而不使用浏览器 •生成的Servlet将实现javax.servlet.jsp.JspPage
- 109.
- 110.
- 111. 页面检查间隔（续） • Page-check-seconds特性确定服务器检查JSP修改的 频率 • 较低的值会提高频率 •较高的值会降低频率 • 值-1将禁止服务器进行此项检查 • 在生产环境中，禁用此特性可以获得较好的性能 • 在weblogic.xml部署描述符的<jsp-descriptor>元素中， 将page-check-seconds参数设置为适当的值
- 112.
- 113.
- 114. verbose • 如果将verbose参数设置为true，则调试信息将输出到 浏览器、命令提示符窗口和WLS日志文件 • 尽管这不是一个重要的因素，但仍可能影响性能 •在weblogic.xml部署描述符<jsp-descriptor>元素中，将 verbose参数设置为适当的值
- 115. Page指令和HTTP会话 • Page指令定义应用于整个JSP页的特性 • 默认情况下，在JSP中使用page指令时，JSP引擎会创建一个 会话对象 •如果JSP中不需要HttpSession，请将会话特性值指定 为false • 避免创建不必要的会话对象 • 减少内存和垃圾回收的开销 • 可以调高性能
- 116. 会话超时 • 只要创建了 HTTPsession对象，它将一直驻留在内存 中，直到发生以下任一情况： • 明确地令该对象失效 • 服务器在特定的一段时间（session timeout）后将其删除 • 服务器关闭 • 以上情况中最先发生的为准 • 会话超时值较大意味着该会话对象会在内存中保留较 长时间 • 如果有大量用户，则会话对象的大小和会话超时值会 影响性能
- 117.
- 118.
- 119. 会话失效 • WLS会定期检查超时和无效的会话。这样做是为了删 除旧的会话，释放内存 • 调整此参数可以提高应用程序的性能，从而提供高流 量 •在weblogic.xml部署描述符<session-descriptor>元素 中，将invalidation-interval-secs参数设置为适当的值
- 120. 关于会话的开发建议 • Session 管理会造成额外开销 •建议使用 setAttribute() 来保存粗粒度对象 • 不要使用很大的 HttpSession 对象 • 如果需要复制Session， • 把session的大小限制在 2-3KB以内 • 尽量使用内存复制
- 121. Servlet开发的其他建议 • 针对Servlet对Servlet调用, forward()比 sendRedirect()性能要好 一些 • 尽量避免在Servlet/JSP中定界事务 • 为提高性能，尽量避免跨越JVMs调用EJB，不要在一个JVM中调用其它 JVM中的 EJBs • Servlets在缺省情况下是多线程的，是线程不安全的 • 单线程模式会降低性能
- 122. 关于日志的建议 • 确保应用程序不会执行过多的标准I/O或做过多的日志 记录 • 日志记录通常会显著降低系统性能 •在生产环境中，要从代码中删除所有 system.out.println()语句，因为仅在开发环境中才需要 使用这些语句来进行调试
- 123. 连接池大小 • 可以通过以下参数控制WLS中的连接池大小 • InitialCapacity（初始容量） • Maximum Capacity（最大容量） • Capacity Increment（容量增长步长） • 可以通过调整这些参数来提高服务器性能 • 在开发模式下， 把初始容量设置小一些，在生产模式 下，把它设置大一些 • 对于存在繁重数据库流量的应用程序，可以考虑使初 始容量等于最大容量
- 124. 收缩频率 • WLS根据使用情况定期将连接池收缩到其初始容量 • “ShrinkFrequency”（收缩频率）参数用于指定收缩 连接池之前等待的秒数 • 设置为0时，禁用收缩。这在生产环境中很有用，可以 调高性能
- 125. 测试连接 • 在将连接池中的某个连接提供给客户端之前，WLS可 以测试该连接 • 通过启用“TestConnection On Reserve”（测试保留的连接 ）参数来指定此操作 • 还可以定期测试连接以检查其有效性 • 通过“Test Frequency”（测试频率）参数指定此操作 • 这两个参数都会降低性能，所以当性能要求比较重要 时，考虑不要进行连接测试
- 126. 行预取 • 行预取可以在一次服务器访问中从服务器向客户端提 取多个行，从而提高性能 • 最佳预取行数取决于查询的具体情况 •一般情况下，在达到某个特定值之前，增大此数字将 提高性能 • 该参数配置仅适用于外部客户端访问，不适用于与 WLS位于同一JVM中的客户端
- 127. 语句缓存 • JDBC中的三种语句类型为： • 语句（不缓存）（Statement） •预处理语句（PreparedStatement） • 可调用语句（CallableStatement） • WLS提供了语句缓存，JDBC语句可以缓存在其中供重 复使用 • 调整缓存参数可以提高性能 • 如果业务逻辑比较复杂，使用存储过程 • 如果一个语句要多次执行，可以考虑使用prepared statement，并且把 缓存调大一些
- 128.
- 129. 批量更新 • 典型应用可能涉及多个数据库操作语句（insert、 update、delete） • 根据需要组合数据库操作语句有助于提高程序性能 •Statement.addBatch()和Statement.executeBatch()可 以让程序进行批量更新
- 130. 组合事务 • 事务操作会产生大量开销，从而显著降低性能 • 将多个操作合并到一个事务中有助于提高性能 •默认情况下，JDBC连接已启用了自动提交 • 每个JDBC语句都作为单独的事务来执行 • 在程序中使用 connection.setAutoCommit(false)关闭 AutoCommit，缺省值为true • 可以使用Connection.start()、Connection.commit()和 Connection.rollback()来区分事务。
- 131. 调整JMS客户端 • JMS共享 • 当可能时，尽量共享和缓存JMS资源 •避免为每个消息创建和关闭连接、会话、消息生成器、消息接 收者或临时目标 • 选择可最大程度地降低内存开销的消息类型 • 使用transient变量降低序列化开销
- 132. 异步消息 • 异步消息 • 性能优于调用只返回void类型的同步方法 •可以更好的管理服务器资源 • 对消息进行排队 • 可以提高性能 • 允许排定优先级（高优先级的消息可能需要先进行处理） • 使用MessageListener实施异步接收消息可以提高性能
- 133. JMS持久性存储 • 为避免持久性开销，在性能要求更重要的情况下，可 以考虑非持久消息 • 如果存储的消息数量增加，则持久性存储在WLS实例 初始化期间需要更多内存 •如果应用程序确实需要持久保持消息，可以增加JVM 的堆以容纳当前存储在持久性存储中的消息
- 134. 集群中的远程调用 • 由于涉及以下操作，远程调用成本很高： • 通过网络发送数据 •为发送数据而进行序列化和反序列化 • 所以，最大限度的减少这类远程调用的次数可以调高 集群的性能 • 有助于最大限度的减少远程调用次数的一些技巧： • 会话外观（Façade Session Bean） • 值对象（Value Object） • 分布式事务处理
- 135. 集群多播通信 • WLS集群需要对特定的IP多播地址和端口进行独占访 问，此访问主要用于传输服务器心跳信号 • 多播数据包在网络上的重复传输被称为多播风暴，多 播风暴会严重损害集群的性能 •增加多播缓冲区的大小会提高传输和接收的速度，防 止多播风暴 • 多个集群可以共享一个多播地址和端口