（续） WEBLOGIC 配置实践
引用地址：http://publishblog.blogchina.com/blog/tb.b?diaryID=5937361关键词： （续） WEBLOGIC 配置实践
消息分页
永久性和非永久性消息消耗服务器内存，除非启用分页。消息分页是释放永久性和非永久性消息所占用的服务器内存的过程，因为永久性消息也会把它们的数据缓存在内存中。一条被换出页面的消息不会释放它使用的所有内存。消息头和消息属性仍然留在内存中，以供查找、排序和过滤之用。在事务性会话中发送的消息只有在会话被提交后才适合于分页。在这之前，消息被保存在内存中。
技巧
· 如果启用JMS分页，而且没有配置分页存储器， WLS 8.1会自动创建一个分页存储器，但是推荐显式地配置页面存储器（您可以指定存储器的位置）。
· JMS分页增加了一个WebLogic Server实例能够包含的消息数据的数量，而不要求增加JVM堆大小。
· 分页的确会降低性能，但是对非永久性消息进行分页时，其效果比对永久性消息分页时要小。
· 始终为WebLogic JMS Server配置限额；限额可以防止消息溢出服务器内存。
流控制
定义JMS服务器之后，您可以配置一个或多个连接工厂，以使用预定义的属性创建连接。借助流控制功能，您可以在消息生产程序确定自己将会变得过载时，引导JMS服务器或目的地降低它的速度。
技巧
· 为了降低过于活跃的、从WebLogic Server 进程之外淹没目的地的生产程序的速度，需要配置流控制。
· 在服务器内部使用流控制会导致服务器线程速度变慢；要小心使用。
部署
WebLogic Server允许您把部署单元存储为单个存档文件，或者是一个包含与上述存档文件相同内容的已展开目录。存档文件是包含一个所有应用程序或模块的类、静态文件、目录和部署描述符文件的单个文件。
在托管服务器实例上部署用户应用程序。这将管理应用程序（控制台）和域配置从用户应用程序分离出来。在生产环境和多服务器环境中，避免使用应用程序的自动部署。以“生产模式”运行WebLogic域将禁止在生产中进行自动部署。如果您创建脚本来把应用程序部署为整个结构的一部分，考虑使用wldeploy Ant任务。
如果您在部署应用程序（或模块）时，在把On Future Redeploys选项设置为Initialize Roles and Policies From DD 之前，一次或多次将其设置为Ignore Roles and Policies From DD，您就可以使用管理控制台设置安全策略和安全角色。但是，使用管理控制台进行的这些修改将覆盖部署描述符中指定的安全性。
技巧
· 使用生产模式运行生产应用程序。
· 避免在管理服务器实例上部署用户应用程序。
· 为了指定服务器的默认Web应用程序，在weblogic.xml或application.xml文件中使用一个空的context-root元素或者一个值为"/" 的元素。
· 在管理控制台中部署应用程序之后，对该应用程序的安全策略的修改将会覆盖部署描述符中的策略。
重新部署
部署一个应用程序之后，您可以重新部署该应用程序本身或者它的一部分。重新部署一个完整的应用程序包括卸载它所有的类，然后使用修改后的文件再次部署该应用程序。在生产中重新部署应用程序是一个很严肃的任务，它可能影响到性能，所以要仔细规划应用程序的更新。
如果生产中有一个Web应用程序正在使用中，重新部署将导致WebLogic Server丢失所有活动的HTTP会话。通过在WebLoigc特定的部署描述符文件(weblogic.xml)中打开一个特殊的属性，可以还原HTTP会话。
技巧
· 如果您只修改了静态文件，那么在不用重新部署整个应用程序的情况下刷新它们是可能的。
· 使用命令行选项部分地重新部署已扩展的应用程序(weblogic.Deployer … -redeploy …)。
· 想要在不改变应用程序的情况下修改部署参数，需要使用备用的部署描述符。
· 为了简化在重新部署期间，把应用程序存档文件重新分布到多个WebLogic Server实例上的过程，需要使用分段模式部署。
· 如果管理服务器不可用，可以以独立模式启动具有全部分段应用程序的托管服务器，并使它的功能完全。
企业应用程序
如果客户端位于相同的企业级应用程序类中，而且可以在企业应用程序中跨所有存档应用程序共享库，WebLogic优化了对EJB的访问。所以，考虑创建企业存档文件，而不是独立部署相关的应用程序。此外还可以使用企业范围内的设置，而不要使用部署描述符中的多项本地设置。使用WebLogic控制台在WebLogic Server域中创建JDBC资源，而不要采用weblogic-application.xml技术。
技巧
· 在WebLogic Server中，避免把EJB存档文件和相关Web应用程序部署为单独的独立应用程序。
· 当Web组件访问同一个企业应用程序中的EJB组件时，可以提高运行时性能。
· 可以把企业部署为一个部署单元。
· 不要把特定于应用程序的类或JAR文件放入系统classpath (避免为了重新加载它们而不得不重新启动服务器)。
· 使用WebLogic Server 8.1时，请使用企业应用程序目录结构中新的APP-INF/lib 和 APP-INF/classes 目录，这是为了简化实用程序类和实用程序存档文件的打包工作。
预编译
生产和测试部署应该包括经过预编译的JSP页面和EJB（使用weblogic.appc，如果是早期的weblogic版本则使用weblogic.jspc /weblogic.ejbc）。在您部署应用程序之前的很长一段时间内，它们可以捕捉该应用程序的错误。此外，离线编译可以验证部署描述符与当前规范的兼容性。部署已编译的应用程序可以缩减部署时间和接下来的服务器重启时间。用在开发人员的工作站上的开发部署可以使用动态编译。
技巧
· 为了在应用程序部署期间或服务器启动期间预先编译JSP文件，在weblogic.jar中启用预编译参数。
· 在生产环境中，要禁止运行时的页面检查和重新编译，需要把pageCheckSeconds 设定为 -1。
· 您可以使用weblogic.appc或weblogic.ejbc (不再使用)在服务器VM之外编译EJB。这可以减少随后服务器的重启时间。
· 在脚本中使用weblogic.Deployer实用程序，或者它相关的Ant任务wldeploy，以便在生产环境中使部署自动化。
部署描述符编辑
只有当重新部署应用程序时，修改J2EE应用程序的部署描述符才会生效。WebLogic管理控制台提供一种方法来修改某些部署描述符属性，而不用重新部署应用程序。当域以开发模式运行时，为了利用这项功能，您必须在已展开的目录结构中部署应用程序（非存档格式）。
为了在部署之后修改应用程序的描述符值（以展开的格式），执行以下操作：Web Application Module > Your Application > Configuration 选项卡 > Descriptor选项卡。
技巧
· 使用WebLogic Server 提供的工具生成和编辑XML部署描述符。
· WebLogic Builder生成描述符；它包括一个用于编辑描述符的接口。
· DDInit 是一个命令行实用工具，用于为WebLogic Server应用程序生成部署描述符。
· ddcreate 是一个 Ant 任务，可以用于为企业应用程序创建部署描述符。
EJB
无状态会话EJB自由池可以提高性能和吞吐量，因为bean是在服务器启动期间或部署期间被创建的。WebLogic Server使用bean实例的缓存来提高有状态会话EJB的性能。该缓存在内存中存储活动的EJB实例，这样它们马上就可以为客户端请求所用。
使用应用程序级/联合缓存将导致碎片减少，而且内存和堆空间的利用率更高。但是应用程序级/联合缓存的使用仅限于企业应用程序中的实体EJB。对于要求高吞吐量的应用程序来说，要使用bean级别的缓存。bean级缓存是高效的，因为任务们不用竞争对联合缓存中一个控制线程的控制权。
为了在应用程序中使用WebLogic为EJB组件提供的调用优化，把设置为true。
在同一个企业应用程序中为要访问的EJB编写本地接口，也可以达到相同的目的。
实体EJB的并发策略包括：
数据库：
遵从数据库可以提高吞吐量（对于EJB1.1和2.0来说，这是默认的也是建议使用的机制）。
互斥的：
避免死锁；只有当在非群集的服务器上要求高度一致性时才使用它。
乐观的：
在事务期间，EJB容器或数据库中不会保持锁定。但是EJB容器确保事务正在更新的数据没有被修改。
只读的：
事务结束时，容器不会试着保存bean的状态；对不会对永久性数据做任何修改的EJB使用这一点。借助只读策略，使用使容器中缓存的bean数据变得无效；当出现超时时，这会更新永久性存储器中数据。
技巧
· 考虑执行线程的数目，以便配置自由池中bean的最大数目。
· 要限制有状态会话EJB使用的内存，需要设置能够驻留在缓存中的bean的最大数目(max-beans-in-cache)。
· 缓存过小会导致频繁的激活和钝化。
· 缓存过大会导致内存浪费。
· 当达到理想的超时时间长短之后，LRU算法会让bean保持在钝化状态。
· 为了避免钝化有状态会话EJB所带来的相关开销，使用Not Recently Used (NRU) 算法。
· EJB的本地接口提供对服务器端EJB客户端的最优访问。
· 联合缓存使管理员能够在weblogic-application.xml中只调整一块缓存，而不是多块缓存。
· 使用容器托管事务的消息驱动bean必须使用XA连接工厂。
安全性
永远不要对生产服务器使用开发模式；开发模式会放宽域中所有服务器的安全限制。使用兼容性安全性时，禁用生产中的客人登录，这样就可以使用客人登录来访问WebLogic Server中的WebLogic资源。
创建安全策略时，如果通过继承得到的策略语句出现在Policy Editor页面的Inherited Policy Statement框中，新的策略会覆盖它们。想要修改在J2EE部署描述符中定义的安全策略，需要进行重新部署；在管理控制台中修改内嵌的LDAP策略是动态的。把另外的管理用户配置为诸如admin、deployer、 monitor 或 operator这样的角色。
SerializedSystemIni.dat包含对域中密码进行处理以后得到的杂乱信息；确保您在安全的地方存储了这个文件的拷贝。只能授予WebLogic系统管理员帐号对SerializedSystemIni.dat的读权限。如果您丢失了管理密码，而且没有以boot.properties文件的形式保存启动身份，那么您不能重新启动服务器。
技巧
· 在boot.properties文件中保存对有权启动WebLogic Server 的用户进行加密后的启动身份。
· BEA建议使用安全角色（而不是用户或组）来保护WebLogic资源；首先把用户指派给组，然后创建角色语句。
· 不要以root权限安装或运行WebLogic Server 。如果您必须绑定到一个要求授权的端口，请在WebLogic机器配置中使用post-bind UID 或 post-bind GID。
· 设置WebLogic安装和应用程序目录的所有权，只允许运行服务器的用户帐户访问它们。
恢复管理员密码
使用默认的身份认证程序时，如果您尚未修改全局的管理角色（默认情况下被授给管理员组），您可以恢复WebLogic域中的管理员密码。
想要恢复WebLogic域中的管理员密码，需要完成以下步骤：
· 在命令行上，修改到域的目录，然后运行setEnv 脚本来设置PATH 和CLASSPATH。
· 创建一个新的 DefaultAuthenticatorInit.ldift；运行 java weblogic.security.utils.AdminAccount ./
· 删除//ldap子目录中的初始化状态文件DefaultAuthenticatormyrealmInit.initialized。
· 使用新的用户身份重新启动服务器。
· 要修改旧的管理用户身份，需要登录到管理控制台。（可选）
SSL
当对WebLogic Server使用SSL时，请使用keystore；已经不再使用把身份（私钥和证书）和信任（CA）保存在文件里这种方法。从早期的版本进行迁移要求您使用私钥、证书或信任文件创建keystore。
如果连接域中WebLogic Server的网络不可信任，在域中的每台服务器上启用SSL，这样管理服务器和托管服务器之间的LDAP复制就可以使用SSL连接。在域中启用管理端口要求所有的服务器都使用SSL。
默认的WebLogic安装代表可输出强度的（exportable-strength） SSL实现（SSL最多可以使用带有批量加密的512位钥匙）。长于512位的钥匙需要BEA提供的内部强度的（domestic-strength）SSL许可证钥匙。如果您在您的生产环境中使用SSL，请使用高强度的（high-strength）SSL。通常认为长度小于1024位的钥匙是不可靠的。
SSL硬件加速器：在WebLogic Server上运行SSL会在很大程度上耗尽服务器的资源。通过卸载SSL处理，就可以把资源应用到WebLogic功能上。Web服务器、负载平衡器、防火墙或交换机都可以进行SSL处理。
在WebLogic Server中，过滤它们可以控制进入的连接。WebLogic Server提高一种默认的连接过滤器实现，您可以在管理控制台种对它进行配置。
技巧
· 在生产中，不要使用与WebLogic一起提供的示例SSL证书。
· 为了避免危及应用程序的安全性，安装并配置特定于服务器的SSL证书，然后在生产服务器上启用主机名验证。
· 只在必要时对WebLogic Server 使用SSL，因为SSL会降低性能。
· 要控制能够被WebLogic Server 实例接受的连接的类型，请使用连接过滤器。
· 使用带有内置安全套接字层（Secure Socket Layer,SSL）支持的负载平衡器，或者使用Java Cryptography Extension（JCE）在有SSL硬件的机器上运行WebLogic Server。
保护管理控制台
如果您使用管理服务器（或者在单台服务器的域中）为应用程序服务，请做到以下几点，以提供更好的安全性：
· 把默认的管理用户及密码修改为定制的用户及密码。
· 修改管理控制台上下文根路径。
· 启用域范围内的管理端口。
· 考虑禁用管理控制台。
如果您使用的是外部LDAP提供程序，把服务器启动身份存储在内嵌的LDAP服务器中，然后在外部LDAP身份认证提供程序上设置超时。这样，如果外部LDAP服务器不可用，您可以继续重新启动，向WebLogic Server提供未受保护的数据。此外，在您应用任何修改之前，把所有身份验证提供程序的控制标志设置为OPTIONAL；这可以防止配置错误导致生产服务器不能重新启动。
基于旧式的安全领域API，WebLogic Server提供一个定制的领域，叫做NTRralm，它可以支持本机的Windows域身份认证。对于没有被设定为使用Active Directory的Windows域来说， NTRealm相当有用。
技巧
· 在内嵌的LDAP服务器中存储服务器启动身份。
· 想要更加出色地控制生产环境，使用Active Directory 身份验证，而不要使用本机的Windows域（NTRealm）身份验证。
· 为了防止拒绝服务攻击，在服务器上修改进入协议端口(T3, COM, IIOP, HTTP Post 超时)的超时和最大大小的值。
· 让内部或外部的审核小组执行安全性审核。
群集
WebLogic群集是域中的一组托管服务器，以一种协同的方式为客户端提供单个服务器视图。使用WebLogic群集来提高效率、可伸缩性、负载平衡和故障恢复。WebLogic群集是一种流程级别的群集，参与其中的服务器可以位于不同的物理机器上，也可以位于同一台机器上。IP多播是在群集中交换心跳信号的枢纽。所以，确保在WebLogic Server网络中启用多播通信。
技巧
· 如果您使用了Web Server代理，那么至少配置两个，以避免群集的单点故障。
· 把WebLogic Server 上的应用程序移植给群集时，确保存储在HTTP会话中的对象能够序列化。
· 至少在每个群集中防止三个WebLogic Server 实例，这样一台服务器的故障就不会停止群集的负载平衡。
· 您不能给群集添加管理服务器。
· 对网络中的每个群集使用单独的多播地址。
· 运行在群集的服务器可以监听WebLogic Server 7.0的不同端口。
· 如果可以，使用单独的硬件 (NIC)来路由群集多播通信 ，具体方法是配置网络频道，把内部群集通信与外部客户端通信分离开来，这样可以获得更好的性能。
· 在一级群集(ex. war and EJB jar)中联合频繁被访问的应用程序，以避免网络信息流过大。
· 要启用servlets和 JSP的自动故障恢复，使用复制技术。
· 内存中的复制比其他类型的复制要快。
· 使用内存中的复制时，要为群集中的服务器指定机器信息。
· 只有当您需要控制二次选择过程时，才需要定义复制组。
· 在所有可能的地方使用服务器相似性可以提高性能。
· 公开使用可用的DNS名称来标识WebLogic Server 实例，而不要使用启用防火墙的环境中的IP地址。
· 如果一个WebLogic群集跨越了多个站点，站点间的网络必须支持跨站点群集的多播通信。
· 借助这个跨越体系结构，您必须把群集的Multicast TTL 值配置得足够高，才能防止路由器在多播包到达其目的地之前丢弃它们。
线程化
为了提高WebLogic Server的性能，请使用本机的I/O（性能包），如果它们可用的话。为了确保能正确初始化性能包，在启动时要检测错误。
可以把执行队列设定为在溢出情形下增加线程。但是，避免使用服务器增加执行线程数目的能力，以管理常规的应用程序负载高峰期。相反地，进行仔细的容量规划和服务器调整；为执行线程选择一个最佳的数目。
技巧
· 只有当CPU利用率没有到达100%，但是客户端请求经常被阻塞和拒绝时，才能调整执行线程的数目。
· 调整线程数目时，如果吞吐量开始下降，或者CPU利用率下降或保持恒定，才能停止调整。
· 不要把Stuck Thread Max Time 和 Stuck Thread Time Interval 设置得过低，以至于在处理高峰期间，常规请求被误认为是卡住得线程。
· 为了划分应用程序组件或者给一个组件提供专门数量的资源，需要创建用户定义的执行队列。使用定制的执行队列还可以避免出现潜在的跨服务器死锁的情形。
· 为了给消息驱动bean提供专门的资源，需要对每个被部署的消息驱动EJB使用一个单独的执行队列。
· 诊断WebLogic Server上的死锁故障和长期运行的请求时，使用一系列正确安排的线程转储来确定可能的原因。
· 如果通过隧道化（tunneling）在HTTP上使T3协议进行访问，性能将下降大约15%；应避免在HTTP上使用隧道化T3。
测试技巧
· 在容量规划和测试期间，要为应用程序可能引起的高峰负载拟订计划。
· 在测试期间优化应用程序；通常，在WebLogic Server 上，应用程序在性能和容量方面是限制最大的因素。
· 在压力下测试系统性能时，要使用适当而现实的测试用例。
· 测试用例与生产情况越贴近，测试结果就越精确。
· 对应用程序进行基准测试时，忽略开始的几个例子；运行测试例子来让服务器VM“进行热身”。
监控
使用特定于操作系统的统计来观察线程行为和上下文切换。例如，在Solaris上，您可以使用mpstat、prstat、top来监控CPU利用率。mpstat公开CPU利用率、线程中断，以及有意和无意的上下文切换。top将帮助您找出耗尽CPU的进程。
WebLogic管理控制台可以用于监控正在运行的服务器、服务器线程、JVM堆的使用情况、日志文件、群集统计信息，等等。启用SNMP监控可以利用现有的SNMP监控框架，以便通过中央管理服务器来监控您的WebLogic域资源。
1.01节：第三方监控工具也可用用于监控WebLogic Server使用的应用程序和系统资源（例如，Quest公司出品的spotlight，Acsera公司出品的Acsera，等等）。
技巧
· SNMP代理是域中管理服务器的一个组成部分，所以管理服务器实例的故障可能变成一个瓶颈。
· 为了监控WebLogic运行时Mbeans，除了管理控制台之外，您还可以使用JMX监控工具。
JVM
使用JVM，它可以给服务器端的应用程序(例如 JRockit)提供更好的性能。管理控制台可以用于图形化地监控JVM堆的使用情况。
为了获得更好的性能，要求使用特定于JVM提供商的选项进行测试。
例如，这些您可以设置的常见“热点”JVM选项：
-XX +AggressiveHeap – 使用几乎和整个物理内存一般大的堆。
-XX +UseISM – 使用隐私的共享内存 (Solaris)。
AggressiveHeap 警告：
1. 使用所有可用的内存。
2. 与 -Xms –Xmx不兼容。
3. 堆可能会从堆栈偷取内存。
隐私的共享内存警告 (仅针对 Solaris):
1. 锁定内存；只在转么系统上使用。
2. 内存碎片能够防止分配连续的4 MB页面。
3. 异常的JVM终止能够导致出现锁定段。
4. 要发现并删除锁定段，使用ipcs 和 ipcrm。
技巧
· 不要把服务器的堆大小设置得比机器上可用的自由RAM还大。
· 为了获得高性能和高吞吐量，设置最小的JVM堆大小等于最大的堆大小。
· WebLogic Server用于低内存情况的日志记录功能可以用于对可用自由内存进行采样，以便检测低内存的情况。
· 监控垃圾收集时，如果堆始终固定在85%空闲，那么试着减小堆大小。
· 进行设置时，-noclassgc确保将perm大小设置为大于默认值(32mb)。
· 在生产运行期间避免使用-verbosegc 选项。
· 在多CPU的机器上使用并行的垃圾收集算法，以减少垃圾收集的暂停时间。
· 在基于Intel的体系结构上，为了获得更好的性能，把WebLogic配置为使用JRockit虚拟机。
· 要发现并删除锁定段，使用ipcs和 ipcrm。
页:
[1]