任何在市场上成功的产品都拥有良好的性能。虽然成为象WebLogic Server这样广泛使用的产品需要具备很多特性,但性能绝对是必不可少的。
良好的编程习惯在帮助应用运行方面起了很大的作用,但是仅有它们还是不够的。应用服务器必须能够在多种硬件和操作系统之间移植,必须具备通用性以便处理范围更广的应用类型。这就是为什么应用服务器都提供了丰富的调试”按钮”的原因,通过调整这些“按钮”,能够使服务器更适合运行环境以及应用程序。
本文针对WebLogic讨论了其中的某些调试参数,不过并未将所有可调整的属性全部列出。此外,在将此处推荐的方法运用到产品环境之前,建议您先在测试环境中对它们测试一番。
性能监控及瓶颈发现
性能调试的第一步是孤立“危险区域”。性能瓶颈可以存在于整个系统的任一部分? D ?维网络,数据库,客户端或应用服务器。重要的是首先确定哪个系统组件引起了性能问题,调试错了组件可能会使情况更糟。
WebLogic 服务器为系统管理员提供了管理控制台和命令行工具两种方式监控系统性能。服务器端有叫作mbean的集合,用于搜集诸如线程消耗情况,资源剩余情况,缓存使用情况等信息。控制台和命令行管理器都可以从服务器将这些信息调用出来,图1的屏幕快照就显示了EJB容器中缓存的使用和剩余情况,这是控制台提供的性能监控的选项之一。
代码分析器也是应用代码用以探测自身性能瓶颈的另一种有效的工具。有几个很好的代码分析器,如:狡猾的 Jprobe内孔窥视仪, Optimizelt。
EJBName空闲
大豆
数豆子
使用
服务员数
总数
超时
总数
缓存
大豆
当前缓存数
访问缓存数
点击
数
激活数
钝化
数
OrderEnt
188
6923
0
0
2000
163186
101005
84476
123618
OrderCustomerEnt
16
1000
0
0
1000
36042
0
0
10926
OrderLineEnt 44
1034
0
0
1000
562590
562590
235086
369863
ItemEnt
563
0
0
549
548190
365460
549
0
OrderCustomerEnt
1000
0
0
1000
34462
0
0
10471
OrderEnt
130
6544
0
0
2000
154985
96312
80588
118189
ItemEnt
545
0
0
535
525375
350250
535
0
OrderLineEnt 43
1033
0
0
1000
538419
538419
225627
355307
图1所示。 采用管理控制台监控系统性能
EJB 容器
EJB容器中最昂贵的操作当然是数据库调用? D ? D装载和存储实体bean。容器也因此提供了各种各样的参数以便减少数据库的访问次数。但不管怎样,除非是在特殊情况下,否则在每个bean的每次交易中,至少都得有一次装载操作和一次存储操作。这些特殊情况是:
1。 豆是只读的。此时,Bean只需在第一次访问时装载一次,从来不需要存储操作。当然,如果超出参数read-timeout-seconds的设置,Bean将被再次装载。
2。 豆有专门的或积极的并发策略,且参数db-is-shared设置为假。此参数在WebLogic服务器 7.0中被重新命名为cache-between-transactions。参数db-is-shared 设置为假相当于参数cache-between-transactions设置为真。
3。 豆在交易中未被修改过,此时,容器会将存储操作优化掉。
如果不属于上述任何一种情况,则代码 路径中的每个实体bean在每次交易时,至少会被装载和存储一次。有些特征能够减少数据库的调用或者降低数据库调用的开销,如:高速缓存技术,域(领域)分组,并发策略以及紧密关联缓存(热切 缓存的关系)等,其中的某些特征是WebLogic服务器 7.0新增的。
高速缓存:实体bean缓存空间的大小由weblogic-ejb-jar.xml中的参数max-beans-in-cache定义。容器在交易中第一次装载bean时是从数据库调用的,此bean时也被放在缓存中。如果缓存的空间太小,有些豆就被滞留在数据库中。这样,如果不考虑前面提到的前两种特殊情况的话,这些豆在下次调用时就必须重新从数据库装载。从缓存调用豆也意味着此时不必调用然后()。如果bean的关键(主)键是组合域或者比较复杂,也能省却设置它们的时间。
良好的编程习惯在帮助应用运行方面起了很大的作用,但是仅有它们还是不够的。应用服务器必须能够在多种硬件和操作系统之间移植,必须具备通用性以便处理范围更广的应用类型。这就是为什么应用服务器都提供了丰富的调试”按钮”的原因,通过调整这些“按钮”,能够使服务器更适合运行环境以及应用程序。
本文针对WebLogic讨论了其中的某些调试参数,不过并未将所有可调整的属性全部列出。此外,在将此处推荐的方法运用到产品环境之前,建议您先在测试环境中对它们测试一番。
性能监控及瓶颈发现
性能调试的第一步是孤立“危险区域”。性能瓶颈可以存在于整个系统的任一部分? D ?维网络,数据库,客户端或应用服务器。重要的是首先确定哪个系统组件引起了性能问题,调试错了组件可能会使情况更糟。
WebLogic 服务器为系统管理员提供了管理控制台和命令行工具两种方式监控系统性能。服务器端有叫作mbean的集合,用于搜集诸如线程消耗情况,资源剩余情况,缓存使用情况等信息。控制台和命令行管理器都可以从服务器将这些信息调用出来,图1的屏幕快照就显示了EJB容器中缓存的使用和剩余情况,这是控制台提供的性能监控的选项之一。
代码分析器也是应用代码用以探测自身性能瓶颈的另一种有效的工具。有几个很好的代码分析器,如:狡猾的 Jprobe内孔窥视仪, Optimizelt。
EJBName空闲
大豆
数豆子
使用
服务员数
总数
超时
总数
缓存
大豆
当前缓存数
访问缓存数
点击
数
激活数
钝化
数
OrderEnt
188
6923
0
0
2000
163186
101005
84476
123618
OrderCustomerEnt
16
1000
0
0
1000
36042
0
0
10926
OrderLineEnt 44
1034
0
0
1000
562590
562590
235086
369863
ItemEnt
563
0
0
549
548190
365460
549
0
OrderCustomerEnt
1000
0
0
1000
34462
0
0
10471
OrderEnt
130
6544
0
0
2000
154985
96312
80588
118189
ItemEnt
545
0
0
535
525375
350250
535
0
OrderLineEnt 43
1033
0
0
1000
538419
538419
225627
355307
图1所示。 采用管理控制台监控系统性能
EJB 容器
EJB容器中最昂贵的操作当然是数据库调用? D ? D装载和存储实体bean。容器也因此提供了各种各样的参数以便减少数据库的访问次数。但不管怎样,除非是在特殊情况下,否则在每个bean的每次交易中,至少都得有一次装载操作和一次存储操作。这些特殊情况是:
1。 豆是只读的。此时,Bean只需在第一次访问时装载一次,从来不需要存储操作。当然,如果超出参数read-timeout-seconds的设置,Bean将被再次装载。
2。 豆有专门的或积极的并发策略,且参数db-is-shared设置为假。此参数在WebLogic服务器 7.0中被重新命名为cache-between-transactions。参数db-is-shared 设置为假相当于参数cache-between-transactions设置为真。
3。 豆在交易中未被修改过,此时,容器会将存储操作优化掉。
如果不属于上述任何一种情况,则代码 路径中的每个实体bean在每次交易时,至少会被装载和存储一次。有些特征能够减少数据库的调用或者降低数据库调用的开销,如:高速缓存技术,域(领域)分组,并发策略以及紧密关联缓存(热切 缓存的关系)等,其中的某些特征是WebLogic服务器 7.0新增的。
高速缓存:实体bean缓存空间的大小由weblogic-ejb-jar.xml中的参数max-beans-in-cache定义。容器在交易中第一次装载bean时是从数据库调用的,此bean时也被放在缓存中。如果缓存的空间太小,有些豆就被滞留在数据库中。这样,如果不考虑前面提到的前两种特殊情况的话,这些豆在下次调用时就必须重新从数据库装载。从缓存调用豆也意味着此时不必调用然后()。如果bean的关键(主)键是组合域或者比较复杂,也能省却设置它们的时间。
