Java开发网 - WebLogic Server 管理最佳实践

Topic: WebLogic Server 管理最佳实践

1.WebLogic Server 管理最佳实践

Posted by: simbapu
Posted on: 2005-07-18 20:00

标题：WebLogic Server 管理最佳实践
作者：Balamurali Kothandaraman
来自：http://dev2dev.bea.com.cn

创建 WebLogic 配置/域

域是一组逻辑上相关的WebLogic Server资源，您可以把它当作单个管理单元进行管理。域将所有的资源和应用程序信息保存在一个基于XML的配置库中。为了在WebLogic Server上部署并运行应用程序，首先要创建域。

推荐使用域配置向导作为创建新域的工具。如果您准备编写脚本来创建域，推荐使用slient模式的域配置向导这个工具。也可以从所提供的“开箱即用”的域模板或定制的域模板来创建WebLogic Server域。

为了创建定制的域模板，请使用配置模板生成器，它是一个单机的Java应用程序，能够让您创建定制的配置和扩展。您可以使用这些配置和扩展来创建和更新域。

域配置向导具有以下属性：

· 向导会引导您完成针对目标环境创建或扩展域的过程。

· 向导可以使用OOB预定义的域模板或定制域模板创建或扩展域。

· 向导将创建config.xml 文件，建立基本的安全性，构造启动脚本，等等。

· 可以使用graphical、console 或 silent模式启动向导。

要以graphical模式启动向导，请运行以下命令之一：

域配置模板生成器具有以下属性：

· 向导会引导您完成创建或扩展配置模板 (JAR file) 的过程。

· 配置向导可以使用已创建的配置（域）模板来创建域。

只能以graphical模式启动配置模板生成器。
要启动配置模板生成器，请运行以下命令之一：

技巧

· 如果 WebLogic Domain/Configuration 分布在多台物理机器上，那么应该只能在管理服务器硬件（机器）上运行域配置向导。

· 并不要求一定在托管服务器硬件上运行域配置向导。

· 在WebLogic Server 安装目录之外创建WebLogic域 (默认情况下，所创建的域位于%BEA_HOME%Ser_projectsdomains ) 。

· 为管理服务器创建启动脚本时，如果脚本(startWebLogic.cmd/sh)没有调用域目录中的weblogic.Server 类，使用这个命令行选项来指定域的位置：-Dweblogic.RootDirectory=path。

· 启动托管服务器(startManagedWebLogic.cmd/sh)时，如果进行设置的话， -Dweblogic.RootDirectory 将被设置为服务器根目录，该目录将被用于存储文件，比如日志文件和托管服务器独立（managed-server independence ，MSI）文件。

服务器启动

管理服务器从配置库(config.xml)加载所有配置。所有相关的托管服务器必须在启动期间连接到运行中的管理服务器。独立的托管服务器可以从本地库(msi-config.xml)加载配置。

如果WebLogic运行在装有Unix操作系统的计算机上，您可以为WebLogic Server进程分配一个UID或GID，以便在计算机执行所有优先的启动操作之后，以root用户的身份进行绑定。如果WebLogic Server用户想要绑定到更高的端口(>1024)，则无需root权限。

技巧
编写使服务器启动自动化的脚本时，考虑以下因素：

· 在域中，必须在任何相关托管服务器之前启动管理服务器。

· 当把托管服务器作为相关服务器启动时，它连接到管理服务器，以便下载配置。

· 当把托管服务器作为独立服务器启动时，检查msi-config.xml 文件是否被存储在服务器根目录中。

· 在Unix中，使用 'nohup' 运行 WebLogic Server启动脚本，以保证即使您注销以后，服务器依然在后台运行。

· 在OS中，为安装和启动服务器创建一个WebLogic Server用户。

· 存储加密后的用户身份，使用boot.properties文件来避免启动脚本中出现硬编码的用户身份。

· 当把服务器绑定到较低端口(<1024)时（这需要root权限），使用 WebLogic UNIX机器配置来绑定UID 或 GID 。

· 为了使WebLogic域中的管理服务器在机器重启期间能够自动重启，使用操作系统提供的daemon进程功能。

o Windows 服务

o UNIX daemon 进程

· 当您使用域配置向导创建域时，域中的管理服务器可以被当成服务。

· 此外，可以使用位于域文件夹中的installservice.cmd和 uninstallservice.cmd 脚本在Windows Service Control Manager (SCM)中添加或删除服务。

· 如果管理服务器和托管服务器是同一台机器，配置管理服务器进程和托管服务器进程之间的OS级服务相关性。

· 配置rc脚本，以便在正确的运行级别上添加WebLogic 启动命令。

启动和关机类
可以把WebLogic Server配置为在启动和正常关机过程中调用类。在服务器初始化所有子系统之后和它给客户端访问开放端口之前，加载并执行启动类。类似地，在服务器启动正常关机进程之前加载关机类。和应用程序文件不同，必须手动地使启动和关机类在已部署服务器地本地classpath中可用。

技巧

· 在启动期间，使服务器级的启动类在已部署WebLogic Server实例的系统classpath 中可用。

· 域中的管理服务器到托管服务器都不能自动部署出现在系统classpath中的类；应用程序级别的类可以分布在域中的管理服务器到目标服务器上。

· 重新部署应用程序时，就会重新加载应用程序级别的启动类。

· 不能动态地重新加载服务器级别的启动类；只能在它们各自的WebLogic Server重新启动时重新加载它们。

· 使用应用程序级别的启动类，而不要定义服务器级别的启动类。

节点管理器
使用WebLogic Server提供的节点管理器功能自动启动托管服务器，或者重新启动出现故障的托管服务器。节点管理器使管理员可以从管理服务器或命令行(weblogic.Admin START…)远程启动托管服务器。这可以通过与管理服务器通信来实现，而不用依赖OS特定的远程登录功能。

此外，除了启动和关闭托管服务器之外，节点管理器还能够监控它所启动的服务器的健康状况。如果进行恰当的配置，在出现故障时，节点管理器能够自动重新启动托管服务器。

技巧

· 使用节点管理器时，显式地配置所托管服务器的有远程启动属性，而不要依靠节点管理器为托管服务器的配置提供的环境。

· 节点管理器只接收来自管理服务器的请求。管理服务器不可用时，想要通过节点管理器远程地重新启动托管服务器是不可能的。

· 把节点管理器配置为一个服务/ daemon。

· 启用托管服务器的自动重启。

· 配置机器在出现故障时自动关闭，以便在节点管理器尝试重新启动一个出现故障的实例之前关闭它。

· 运行在一台机器上的节点管理器可以被运行在该机器上的多台托管服务器所共享。

· 节点管理器还可以被运行在同一台机器上的多个域中的托管服务器所共享。

WebLogic Server 关闭过程
异常的JVM终止可以导致套接字或程序段这样的资源被锁定。在操作系统中关闭或终止WebLogic Server进程被认为是异常终止。
可以通过以下方式正常关闭WebLogic Server：

· 使用管理控制台'Graceful Shutdown" 超链接。

· 使用 weblogic.Admin SHUTDOWN… 命令。

· 使用JMX，具体是调用 ServerMBean 类的stop方法。

技巧

· 为了正常关闭生产服务器，需要使用WebLogic 管理控制台或者weblogic.Admin 实用程序。

· 正常关机不会异常终止用户会话；它等待HTTP会话完成或超时。

· 也可以把WebLogic Server配置为不等待（忽略Session During Shutdown 选项）。

· 正常关机超时是可配置的；默认情况下，服务器将会无限期地等待关机过程完成。

· 如果服务器没有响应正常关机请求，或者当服务器等待正在进行的会话时（处于待机状态）关闭服务器，使用'Force Shutdown' 选项。

· 如果被配置为daemon，确保将rc脚本中的stop方法配置为在机器重启和停止时正常关闭服务器。

· 如果对节点管理器进行配置，终止节点管理器将不会停止由它们启动的相应服务器。必须单独地停止各台托管服务器。

备份和恢复
为了在出现故障时迁移或恢复WebLogic域，定期备份管理服务器机器上的整个域目录树。这样，您就可以从硬件或系统故障中恢复，而要做的不过是还原域目录并重新启动管理服务器。

如果管理服务器崩溃，管理服务器将会把所有正在运行的托管服务器的相关信息保留在running-managed-servers.xml文件中。重新启动时，管理服务器将会读取这个文件，并尝试联系所有以前运行的托管服务器。如果没有托管服务器正在运行的话，discovery模式可能会增加管理服务器的启动时间，但是始终要使用discovery模式（默认情况下它是打开的），这样才能保证有托管服务器已经运行的情况下，管理服务器重新与所有托管服务器连接。

一些需要引起注意/定期从管理服务器机器上进行备份的重要文件有：

· config.xml
域配置库。

· config.xml.booted
成功启动时对域配置库的良好备份。

· boot.properties
启动管理服务器时需要的加密后的用户名和密码。

· running-managed-servers.xml
这是当前正在运行的相关托管服务器的一个列表。这个文件用于当管理服务器重新启动后，而且有托管服务器正在运行时，发现托管服务器。

· domain/configArchive/
包含域配置库文件的拷贝。使用管理工具进行更新时，管理服务器把旧的config.xml 文件复制到这个目录。

· domaindminserverdapdapfiles
当前被域的管理服务器使用的内嵌LDAP 数据文件。

· *.ldift 文件
这些文件可以用于把WebLogic Domain Embedded LDAP 服务器初始化为刚刚创建域时的样子。

· domain/adminserver/ldap/backup/EmbeddedLDAPBackup.zip
WebLogic Domain Embedded LDAP 服务器的备份。内嵌的LDAP被用于存储用户、组、角色、默认的安全领域使用的策略、myrealm的安全提供程序。

· Batch/Shell 脚本
setEnv.cmd/sh, startWebLogic.cmd/sh, startManagedWebLogic.cmd/sh。

为管理任务编写脚本
为了创建用于管理域配置的脚本：

· 使用weblogic.Admin实用程序命令BATCHUPDATE，它运行一个批处理文件中指定的一系列命令。这个命令使用一个JVM运行所有列出的命令。

· -Dweblogic.system.BootIdentityFile选项让您可以避免把用户名和密码硬编码在您的文本脚本中。

· 为了在操作系统脚本中构建逻辑分支，使用下面的命令求出weblogic.Admin命令的返回代码：

o %ERRORLEVEL% (Windows)

o 0 (bash shell)

· weblogic.Admin 的-adminurl 选项从管理服务器检索托管服务器的配置Mbean和运行时Mbean。

· 不推荐直接修改config.xml文件。

· 如果您必须修改config.xml文件：

o 首先，在编辑之前备份原始文件。

o 使用XML 编辑器，以避免录入错误。

o 当管理服务器正在运行时，要避免编辑该文件。

· 使用wlconfig Ant任务来为配置信息编写脚本，并把它集成到整个构建过程中。

· 当管理服务器正在运行并且处于离线状态时，使用 WebLogic Scripting Tool (WLST)来修改域配置。 (dev2dev.bea.com)

· WLST提供一个功能强大的到WebLogic Server的shell接口，而且它使用Jython 作为脚本语言。

· 您还可以使用第三方的解决方案来管理配置，比如WLShell使用程序。 (www.wlshell.com)

· WLShell提供一个功能强大的、Unix风格的到WebLogic Server的shell接口；它针对WebLogic Server MBean使用文件系统模拟。

日志记录
日志记录了和事件（比如服务器的启动和关闭）、新应用程序的部署或者一个或多个子系统故障有关的信息。日志消息包括和事件的时间与日期，以及启动事件用户的ID有关的信息。每个WebLogic Server实例都可以维护一份服务器日志、一份HTTP访问日志、一份JDBC日志和一份JTA事务日志。

技巧

· 为了防止当日志文件所占空间过大时，出现相应的服务器重启的情况，需要启用日志旋转（log rotation）。

· 考虑按照大小旋转日志，而不是按照生成的时间旋转，因为使用生成时间这个选项会使文件增长非常迅速。

· 如果您没有进行交互式调试，而且WebLogic Server 是在后台（Windows 或 Unix）启动的，使用以下命令把stdout和stderr重定向到一个文件：

o -Dweblogic.Stdout="stdout-filename"

o -Dweblogic.Stderr="stderr-filename"

· 在生产中，如果您不启用WebLogic Server创建JDBC日志，您就可以避免服务器上的额外文件I/O。

· 使用节点管理器启动托管服务器时，节点管理器捕捉服务器的stdout并把它存储到一个文件中。可以使用管理控制台来查看该文件的内容。

· 经常检查WebLogic Server 的日志文件，以熟悉常规操作，这样您就能够很容易地辨认出异常的日志项。

JDBC
在WebLogic Server中，使用池缓冲到数据库的JDBC连接可以提高应用程序的性能。连接池根除了为每个应用程序创建新的数据库连接的需要。JDBC连接池提供到您数据库的现成连接。

使用连接池时，到数据库的连接的数目可以动态改变。但是，在负载高峰时期试图增加JDBC连接的数目将会使情况恶化，因为创建数据库连接是一项开销昂贵的操作。

连接池还可以通过缓存用于重用的prepared statement和callable statement来提高性能。重用prepared statement和callable statement可以降低数据库服务器上的CPU利用率。

通过把其他应用程序分离到单独的机器或硬件上，可以避免耗尽WebLogic Server机器上的处理能力；为数据库指派一台专用的机器。

技巧

· 如果有可能，按大小排列数据库连接池，这样它们就永远不会增加连接的数目；设置初始容量为最大容量。

· 设置连接池的最大容量至少等于执行线程的数量。

· 配置 Inactive Connection Timeout，以指定一个连接在被回收到池中之前，保持非活动状态的时间长短。

· Connection Leak Profiling选项显示了连接池中泄漏的连接。BEA建议您不要在生产中使用这个选项；它要使用额外的资源，并且通常会降低连接池操作的速度。

· 如果您能够负担把测试连接作为常规请求处理一部分所带来的开销，您可以只使用Test Reserved Connections 选项。

· 避免对“Test Table Name”使用生产表，而要使用哑表(例如Dual)。

· 使用语句缓存提高prepared 和 callable statement的性能。

· 为缓存选择 least-recently-used (LRU) 算法；这将从缓存中删除很少使用的语句。

· 当创建连接池或者启动WebLogic Server时，如果数据库不可访问，可以使用Connection Creation Retry Frequency 重新尝试建立到数据库的连接。

· 当WebLogic Server 正在运行时，如果重新启动数据库， Test Frequency可以从0开始增加，这样所有连接都会被关闭，然后被重新打开，以重新建立有效的物理连接。在重新创建所有连接之后，将它改回0将禁止测试。

· 当为连接池使用DataSource对象时，使用 Honors Global Transaction选项来创建TxDataSource。

· 您应该使用non-Tx DataSource的惟一场合就是当您想在数据库上完成一些工作，而又不想把该数据库包括到当前事务中时。

· 当配置一个连接池，以便与WebLogic JMS JDBC Store 一起使用时，使用non-XA 数据库驱动程序。

JMS
WebLogic Server JMS体系结构允许在一个WebLogic域中创建多台JMS服务器。但是每台JMS服务器只能在一台WebLogic Server上被实例化（目标化），因为它是一项“仅一次”的服务。一台JMS服务器可以作为多个目的地的宿主。永久性存储（基于磁盘的文件或可通过JDBC访问的数据库）可以被配置用于存储永久性的消息数据。

如果必须跨多个目的地共享一个JMS存储器，将多个目的地配置为驻留在一台JMS服务器上。但是，为了使用对每个目的地使用单独的永久性存储器，在多台JMS服务器下创建它们。

技巧

· 针对JMS文件存储启用直接写入同步写入策略，这可以释放虚拟内存（VM）堆，但是只有当存在一些并发的活动JMS客户端时，直接写入可以显著地提高性能。

· 在单独的磁盘上，或者甚至是在单独的磁盘控制器上分离文件存储。

· 为了使文件存储高度可用，您可以使用Storage Area Network (SAN)，一种多端口的磁盘或者磁盘镜像技术。

· 不要把使用XA JDBC 驱动程序的连接池与JMS JDBC存储器关联起来，因为JMS JDBC存储器不支持XA 资源驱动程序(WebLogic JMS实现了它自己的XA资源)。

· 使用Using Expiration Scan Interval扫描目的地的到期消息可以释放VM，但是太频繁的扫描会增加扫描开销；确保您对此做最优调整。

· 在连接工厂上设置 MessagesMaximum ，以便调整异步消息管道的大小。

· 为了避免消息增长，在连接工厂级别上设置 Time To Live 属性。

· 禁用默认的JMS连接工厂；针对生产配置特定于应用程序的JMS连接工厂。

· 为跨物理目的地（在不同的JMS服务器中进行配置）的负载平衡JMS消息配置一个分布式的目的地。

· 当部署分布式目的地时，针对群集中的每台JMS服务器和成员目的地使用类似的设置。

消息分页
永久性和非永久性消息消耗服务器内存，除非启用分页。消息分页是释放永久性和非永久性消息所占用的服务器内存的过程，因为永久性消息也会把它们的数据缓存在内存中。一条被换出页面的消息不会释放它使用的所有内存。消息头和消息属性仍然留在内存中，以供查找、排序和过滤之用。在事务性会话中发送的消息只有在会话被提交后才适合于分页。在这之前，消息被保存在内存中。

技巧

· 如果启用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 <files>…)。

· 想要在不改变应用程序的情况下修改部署参数，需要使用备用的部署描述符。

· 为了简化在重新部署期间，把应用程序存档文件重新分布到多个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组件提供的调用优化，把<enable-call-by-reference>设置为true。

在同一个企业应用程序中为要访问的EJB编写本地接口，也可以达到相同的目的。

实体EJB的并发策略包括：

数据库：
遵从数据库可以提高吞吐量（对于EJB1.1和2.0来说，这是默认的也是建议使用的机制）。

互斥的：
避免死锁；只有当在非群集的服务器上要求高度一致性时才使用它。

乐观的：
在事务期间，EJB容器或数据库中不会保持锁定。但是EJB容器确保事务正在更新的数据没有被修改。

只读的：
事务结束时，容器不会试着保存bean的状态；对不会对永久性数据做任何修改的EJB使用这一点。借助只读策略，使用<read-time-out-seconds>使容器中缓存的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 <tempadmin> <temppassword> ./

· 删除<Domain>/<Server>/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。