Dick的一些技术文章收集,在对本人有帮助的同时,如果也给你带来了一些帮助,那么,这个BLOG的目的就达到了。

发布新日志

  • GBK编码和UTF-8编码的区别(转载)

    2007-06-27 15:00:18

    今天在学习Discuz论坛的时候,发现有GBK和UTF-8的两种论坛下载,我不知道他们有什么区别,于是搜索了一下,知道了他们的区别,复制如下,呵呵。

    1.
        GBK的文字编码是双字节来表示的,即不论中、英文字符均使用双字节来表示,只不过为区分中文,将其最高位都定成1。
        UTF-8编码则是用以解决国际上字符的一种多字节编码,它对英文使用8位(即一个字节),中文使用24位(三个字节)来编码。对于英文字符较多的论坛则用UTF-8节省空间。

    2.
        GBK包含全部中文字符,
        UTF-8则包含全世界所有国家需要用到的字符。

    3.
        GBK是在国家标准GB2312基础上扩容后兼容GB2312的标准(好像还不是国家标准)
        UTF-8编码的文字可以在各国各种支持UTF8字符集的浏览器上显示。
        比如,如果是UTF8编码,则在外国人的英文IE上也能显示中文,而无需他们下载IE的中文语言支持包。所以,对于英文比较多的论坛,使用GBK则每个字符占用2个字节,而使用UTF-8英文却只占一个字节。

  • 从传统OA到协同OA

    2007-02-12 11:26:45

    转载自 上海道安公司论坛

    http://www.daoan.com/forums/index.php?mods=topicdisplay&forumid=2&postid=6&PHPSESSID=7011dc7dc01077d374337398c0a1bdf4

    从传统OA到协同OA

    提及OA,人们往往会很自然的把它与"档案管理"、"公文流转"等联系在一起,这也是脱胎于政府收发文的OA给人们留下的根深蒂固的印象。在二十多年的发展历程中,OA自身的局限性使得它所扮演的角色更像是一个"文秘"――企业需要依靠它来进行一些基本的行政事务处理,但同时却很难从中获得更多的价值,这就是办公自动化系统所处的现实和困境,也是企业用户对传统OA不满意的焦点所在。

      而今天,随着协同软件理论和技术的日趋成熟,协同OA应运产生。它源自传统OA,但又完全摆脱了原有的局限,并凸现出其不同与传统OA的应用和更高层面的价值。

      在阐述传统OA和协同OA的区别之前,让我们来回顾一下OA的发展历程及其相应的特点。

      回顾:办公自动化的发展过程

      第一代OA起源于政府公文和档案管理的需求,它实施了企业部分工作流程的自动化和文档的电子化管理。它的特点是以公文处理、档案管理为核心,办公其实就是办文,并形成了以后OA的基本体系。此时OA的架设也多在C/S下,无法很好的支持远程办公和移动办公。

      第二代OA是从90年代中期开始,随着互联网(Internet)的兴起与发展而产生的。以Internet为基础,第二代OA实现了B/S架构,并很好的支持了移动办公的需求,企业资源不再受到通讯技术的限制。同时,OA系统也加入了更多的功能,如BBS、新闻发布、日程安排、人事信息等,但从本质上来说第二代OA依然以公文和档案管理为核心内容。

      90年代末期开始,随着市场环境的变化和协同管理(Collaboration)的兴起,OA的指导思想开始发生转变,更多的强调跨地域、跨部门之间的协同,OA中也加入了新的协作工具,如即时通讯、项目管理、网络会议、文档共享等等,第三代OA出现了。但此时的OA还是没有完全突破传统OA的局限,实现的协作也仅是局部的、浅层次的;更多的企业资源依然处于割裂和难以管理的状态。

      纵观OA的发展历程,我们发现,办公自动化很多时候作的工作不过是将手工进行的事务搬到计算机网络上,并利用了计算机技术的一些先进特点,而其本身却没有增加多少先进的管理理念和方法。另外,起源于政府的公文和档案管理的OA也一直很难摆脱最初的定义模式,除了将企业的一些文档、信息进行了电子化,并在工作流管理上有所增强外,并未给企业带来更多的价值。同时,尽管第三代OA开始加入新的理念如"协同",但从根本上来说,它只是利用了一些简单的协作工具,从企业管理的整体角度来看,它离真正的"协同"还有相当的距离。

        现状:用户面对的OA系统

      了解了OA的发展历程和基本特性后,我们不禁要问,那么现在用户面对的办公自动化系统又是怎样的一个情况呢?

      第一类OA沿袭传统OA,简单和低价

      开发和销售这种产品的企业很多,也有一定的客户群。这类产品价格和开发成本都比较低,它的功能主要是以传统的收发文管理,档案管理为主。并加入了一些辅助功能如,BBS、公告板、名片夹、日程安排、报告管理、图书管理、车辆管理、公司大事记等小功能。这些功能比较简单且相对独立,其中包含的各种信息依然以"孤立"和"静态"的形式存在。总体上来说,这类OA只能帮助企业迈入"办公自动化"的初级阶段,对希望利用OA提高管理水平的企业来说并没有多大实质性的帮助。

      第二类OA实现了部分的协作,有一定灵活性。

      第二类OA相对来说是比较先进的OA,它开始纳入一定的协同管理思想,在功能上也进行了相当的改进,除了对工作流程的功能进行了加强之外,还利用各种协作工具实现人与人之间、部门与部门之间的协同,OA的架构也比较灵活,然而它各方面的功能还是相对独立的,尤其是与企业的业务还是没有实现更深层次的对接,其"办公"涵义的广度和深度也没有达到一个更高的层面。

      面对办公自动化的现状,我们会问:办公自动化到底应该为企业带来什么应用价值?它将何去何从?实际上,这是两个相关的问题,解决方法的获得必须要有更高的高度,更宽阔的视野来看待办公自动化的涵义。我们需要的是重新审视企业的管理和信息化需求,从而挖掘OA新的应用价值。

      思考:寻求OA的价值

      让我们先来看一下现实情况中的企业办公情况。办公,这里也可以理解为"日常的工作"。这个日常工作的涵义是很广泛的。从人员应用的角度来看,企业管理者希望随时了解整个公司的运作情况,与各部门保持经常性的沟通和交流,从人力资源、财务等方面监控企业的整体情况并支持决策,因此他关注"监控和决策";部门领导希望方便的分配工作任务,查看下属的工作进展情况,对其做出相应的指导,对业绩进行评价,并与上下级和其他部门建立紧密的联系,因此他关注"管理和协调";普通员工希望可以查看自己的工作计划和进度,很方便的利用各种管理工具,例如文档管理、知识库、客户管理、项目管理等完成自己的工作任务,因此他关注"高效和协作"。而从应用内容的角度来看,日常工作事实上涵盖了对知识、文档、人员、资产、财务、项目等方面的管理,并且每个管理的环节都关联紧密,相互作用。因此在现实情况中办公的涵义远远超出了我们既定的范围,传统OA只是从一个狭义和片面的角度去实现了"办公自动化"。因此OA应该从更广阔的角度来考虑"办公"的涵义,并与企业的需求进行紧密的结合。

      再来看一下企业当前的信息化现状。我们发现,过去的很多应用系统都是相互割裂的,它们往往关注单个或局部资源的管理,相互之间很少能够紧密协调起来,"信息孤岛"、"应用孤岛"和"资源孤岛"三大难题不可避免的存在。企业常常面临沟通不畅,信息无法及时获得,管理效率低下,资源和资源之间各自为政,难以统一管理和协调的现状。尤其是当企业业务流程日益复杂,业务与业务之间关联与交叉频繁;人与人,部门与部门,企业与企业的沟通和协作愈发凸现重要性的时候,企业更需要打破各种沟通和管理的屏障,实现对管理和运营各环节的掌控、调配和协作。而传统OA由于其应用的局限性难以满足企业"协同管理"的需求。因此协同理念和协同应用应该更多的被纳入OA中,使其可以对企业各种分散存在或被分隔的资源进行整合,从而让企业的管理真正提升到一个新的层面。

      从以上可以看出,一方面我们应该延展和深化OA的应用,另一方面需要将协同的理念纳入OA中,于是便催生了新一代的办公自动化系统――协同OA。

        协同OA基于全新的管理理念和功能体系而设计,因而它呈现出完全不同于传统OA的特性。

      信息网状思想:将各种分散的、不规则存在的信息整合成一张"信息网";业务关联思想:对各种业务环节进行整合并实现在统一平台上的统筹管理;随需而应思想:企业的各种资源,可以被迅速找到并集合到一起,并实现它们之间通畅的沟通和协作。

      基于这三大基本思想体系设计的协同OA一方面打造了高度"协同"的管理和办公环境,另一方面大大深化了OA的应用,从而完全突破了传统OA的局限,有效帮助企业整合各种资源,提升管理:

      关联:企业的分析和决策来源于准确、全面和及时的信息,而"孤岛式"的信息一方面很难全面反应真实的情况,另一方面也容易造成数据混乱、更新不及时、难以统一管理和获取等问题。在传统OA中,例如销售经理要审批一项费用报销单,如果他对这笔费用的来龙去脉不清楚,就很难从这张报销单上获得更多的信息,因为他所获得的仅仅是一些静态的,表面的信息;这个时候他可能要通过不同的应用系统去查询更多的信息,或者与相关人员进行交流,这样就大大降低了工作的效率和准确性。而在协同OA中,由于信息之间已经建立了各种关联,因而销售经理可以从这张报销单开始,迅速提取其他的相关信息,如报销事件的来龙去脉、涉及到的客户或项目、提交人的情况、原始单据或凭证的扫描等,同时又不必在不同的应用系统之间切换。通过这样的关联,为企业真实的还原了信息本来的"网状结构",从而为管理扫除了信息获取不全面和不及时的障碍。

      深化:企业管理涉及到的环节是众多的。现代化企业就象一台不停运转着的精密机器,而各种管理和运营环节就象是机器上的各个部件,相互之间有着千丝万缕的关系,并且必须为企业的共同目标而实现一致性的运作。例如一个产品的销售,涉及到产品的功能和质量(产品研发、质量监控及升级)、产品的市场宣传(宣传平台、宣传文件和方式)、具体销售业务的开展(客户管理、项目跟踪、合同签订)、相关费用的报销(单据填写、流程审批、数据更新)等,而这些业务是否能够被很好的管理并实现统一性的协调将直接影响到产品的销售成果。传统OA由于其局限性,所涵盖的管理深度及广度都是十分有限的,因而很难对这样的一些比较复杂的业务过程进行管理,当然就更难以支持整个业务链的平滑运作了。而在协同OA中,对管理范畴进行了深化和延伸,因而可以让企业方便的对更多的环节进行整合和统筹管理。
      协作:要实现良好的协作,首先需要突破物理边界和组织边界,让处于不同的地理位置,不同组织的人员可以进行无障碍的沟通;其次,需要对整个的协作进行管理,让协作的对象为共同目标而进行一致性的、协调的动作,对协作过程进行监控、调整,对协作产生的信息进行完整的保留,并以知识的方式进行再利用;第三,由于协作发生在企业的各个运营环节中,因此还需要一定的应用广度来支持对其的管理。在传统OA中,协作往往是浅层次的,邮件、BBS、即时聊天工具、工作流程等虽然可以实现一部分的协作,然而它们的涵盖面十分有限,沟通的内容零散,之后也很难对其结果进行进一步的整理。而在协同OA中,由于各种资源之间的屏障被打破,因而这样的协作可以贯穿于各个环节并容易得到集中的管理。如协作的内容可以是企业积累的各种知识文档,项目进展中的某个任务,或是企业的一个合同会签流程,一种需要分配的物资;协作的对象可以是一人对一人,或多人对多人,可以发生在企业同一部门员工之间,也可以发生在跨部门员工之间,还可以是不同企业,企业与客户或合作伙伴之间的协作;协作的方式可以是知识文档、主题讨论区、网上会议、即时聊天、任务分配等。同时,协作的过程和结果可以得到很好的记录,并最终形成知识体系的一部分。

      总结来说,协同OA基于三大基本思想体系,在"关联"、"深化"和"协作"方面体现了其完全不同于传统OA的应用,把OA与企业管理的需求真正的相结合,从而给"办公自动化"带来了更高层面的价值。

  • Weblogic服务器性能调优

    2007-02-07 10:12:30

    转自CSDN

    http://blog.csdn.net/ccsdba/archive/2006/08/06/1029397.aspx

    Weblogic服务器性能调优

           注:在下面做的介绍都是以Weblogic8.1为例的,其它版本的Weblogic可能会有些许不同。

           1) 设置JAVA参数;

           a) 编辑Weblogic Server启动脚本文件;

    l         BEA_HOME\user_projects\domains\domain-name\startWebLogic.cmd(startWebLogic.sh on Unix)

    l         BEA_HOME\user_projects\domains\domain-name\startManagedWebLogic.cmd(startManagedWebLogic.sh on Unix)

    b) 编辑set JAVA_OPTIONS命令,如:set JAVA_OPTIONS=-Xms256m –Xmx256m

    c) 保存,重启即可。

    注:在WebLogic中,为了获得更好的性能,BEA公司推荐最小Java堆等于最大Java堆。

    2) 开发模式 vs. 产品模式;

    开发模式和产品模式的一些参数的默认值不同,可能会对性能造成影响,下面是对性能有影响的参数列表:

    参数

    开发模式默认值

    产品模式默认值

    Execute Queue: Thread Count

    15 threads

    25 threads

    JDBC Connection Pool: MaxCapacity

    15 connnections

    25 connections

           通过启动管理控制台,在域(如:mydomain> 配置 > 常规选择产品模式。

    3) 尽量开启本地I/O

    通过启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver> 配置 > 调整选择启用本地I/O

    注:此值也可通过手动的修改config.xml配置文件。

    4) 调优执行队列线程;

    a) 修改默认执行线程数

    在这里,执行队列的线程数表示执行队列能够同时执行的操作的数量。但此值不是设的越大越好,应该恰到好处的去设置它,太小了,执行队列中将会积累很多待处理的任务,太大了,则会消耗大量的系统资源从而影响整体的性能。在产品模式下默认为25个执行线程。

    为了设置理想的执行队列的线程数,我们可以启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver> 监视 > 性能中监控最大负载时执行队列的吞吐量和队列中的等待请求数,据此确定理想的数值。

           理想的默认执行线程数是由多方面的因素决定的,比如机器CPU性能、总体体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。随着CPU个数的增加,WebLogic可以近乎线性地提高线程数。线程数越多,花费在线程切换的时间也就越多;线程数越小,CPU可能无法得到充分的利用。为获取一个理想的线程数,需要经过反复的测试。在测试中,可以以25*CPU个数为基准进行调整。当空闲线程较少,CPU利用率较低时,可以适当增加线程数的大小(每五个递增)。对于PC ServerWindows 2000,则最好每个CPU小于50个线程,以CPU利用率为90%左右为最佳。

           通过启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver> Execute Queue > weblogic.kernel.Defalt > 配置中修改线程计数。

           b) 设定执行队列的溢出条件;

           Weblogic Server提供给默认的执行队列或用户自定义的执行队列自定义溢出条件的功能,当满足此溢出条件时,服务器改变其状态为“警告”状态,并且额外的再分配一些线程去处理在队列中的请求,而达到降低队列长度的目的。

           通过启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver> Execute Queue > weblogic.kernel.Defalt > 配置下面几项:

    l         队列长度:此值表示执行队列中可容纳的最大请求数,默认值是65536,最后不要手动改变此值。

    l         队列长度阈值百分比:此值表示溢出条件,在此服务器指出队列溢出之前可以达到的队列长度大小的百分比。

    l         线程数增加:当检测到溢出条件时,将增加到执行队列中的线程数量。如果CPU和内存不是足够的高,尽量不要改变默认值“0”。因为Weblogic一旦增加后不会自动缩减,虽然最终可能确实起到了降低请求的作用,但在将来的运行中将影响程序的性能。

    l         最大线程数:为了防止创建过多的线程数量,可以通过设定最大的线程数进行控制。

    在实际的应用场景中,应根据具体情况适当的调整以上参数。

    c) 设定执行队列监测行为

    Weblogic Server能够自动监测到当一个执行线程变为“阻塞”。变为“阻塞”状态的执行线程将无法完成当前的工作,也无法再执行新请求。如果执行队列中的所有执行线程都变为“阻塞”状态,Weblogic server可能改变状态为“警告”或“严重”状态。如果Weblogic server变为“严重”状态,可以通过Node Manager来自动关闭此服务器并重新启动它。具体请参考:Node Manager Capabilities文档。

    通过启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver>配置 > 调整下可配置下面几项:

    l         阻塞线程最长时间:在此服务器将线程诊断为阻塞线程之前,线程必须连续工作的时间长度()。默认情况下,WebLogic Server 认为线程在连续工作 600 秒后成为阻塞线程。

    l         阻塞线程计时器间隔:WebLogic Server 定期扫描线程以查看它们是否已经连续工作了 "阻塞线程最长时间" 字段中指定的时间长度的间隔时间()。默认情况下,WebLogic Server 将此时间间隔设置为 600 秒。

    5) 调优TCP连接缓存数;

    WebLogic ServerAccept Backlog参数规定服务器向操作系统请求的队列大小,默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。Login TimeoutSSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。

    通过启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver>配置 > 调整下可配置“接受预备连接”。

    6) 改变Java编译器;

    标准的Java编译器是javac,但编译JSP servlets速度太慢,为了提高编译速度,可以使用sjjikes编译器取代javac编译器。下面说说更改Java编译器:

    通过启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver>配置 > 常规下改变Java 编译器,默认为javac。输入完整路径,如:c:\visualcafe31\bin\sj.exe。然后打开高级选项,在预规划到类路径填写编译 Java 代码时为 Java 编译器类路径预规划的选项,如:BEA_HOME\jdk141_02\jre\lib\rt.jar

    7) 使用Webogic Server集群提高性能;

    具体关于如何配置Weblogic集群,我就不细说了。详情可参考:Introduction to WebLogic Server Clustering

    8) Weblogic EJB调优

    由于EJB2.0已经很少项目在用了,EJB3.0再成熟一点,我再补充这一部分吧!

    9) JDBC应用调优

    JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗,建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致。

    增加Statement Cache Size对于大量使用PreparedStatement对象的应用程序很有帮助,WebLogic能够为每一个连接缓存这些对象,此值默认为10。在保证数据库游标大小足够的前提下,可以根据需要提高Statement Cache Size。比如当你设置连接数为25,Cache Size10,数据库可能需要打开25*10=250个游标。不幸的是,当遇到与PreparedStatement Cache有关的应用程序错误时,你需要将Cache Size设置为0

    尽管JDBC Connection Pool提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved ConnectionsTest Released Connections也无需勾上。 当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开。

    最后提一下驱动程序类型的选择,Oracle为例,Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。所以在通常情况下建议使用thin驱动。而最新驱动器由于WebLogic server/bin目录下的类包可能不是最新的,请以Oracle网站为准: http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html

    10) JSP调优

    l         设置jsp-param pageCheckSeconds=-1

    l         设置serlet-reload-check=-1ServletReloadCheckSecs=-1

    l         设置jsp-param precompile=true,关闭JSP预编译选项。 

     

  • LoadRunner之---解决回放时浏览器乱码问题

    2007-01-09 11:16:27

    转载自希赛博客

    http://blog.csai.cn/user1/21289/archives/2006/9323.html

    经本人验证,此方法有效:)

    用LR回放时,浏览器显示乱码的问题,相信大家都遇到过,那么怎么解决呢?

    下面我就选取浏览器IE6.0中文版,给大家讲解一下。

    首先,设置Run-time Settings-Browser-Browser Emulation-Change。具体设置见下图。


    然后,设置IE,查看-编码-钩上“自动选择”和Unicode(UTF-8)。

    现在回放一下脚本吧,看看是不是变回期待已久的中文了

  • WebLogic Portal 9.2中的新联邦特性

    2006-12-31 10:19:56

    http://dev2dev.bea.com.cn/techdoc/20060630872.html

    转载自BEA中文网

    时间:2006-08-30
    作者:Alex Toussaint
    浏览次数: 537
    本文关键字:Web Services for Remote PortletsWSRPfederationportletAquaLogic Service BusAquaLogic Service RegistryWebLogic PortalAlex Toussaint联邦WebLogic Portal 9.2

    摘要

      构建应用程序的面向服务架构的方法提高了企业和IT的生产力、敏捷性和速度。为了帮助实现这些获益,BEA WebLogic Portal支持发布和使用portlet的业界标准技术,这些portlet整合了用户交互和服务功能逻辑。WebLogic Portal的门户联邦功能基于Web Services for Remote Portlets (WSRP)技术,支持分布式企业门户服务结构,此结构可被轻松结合,以支持企业快速响应并向门户客户交付最佳用户体验。

      WebLogic Portal 9.2扩展了WebLogic Portal 8.1中首次引入的门户联邦功能。本文主要介绍这些新的联邦特性。另外,WebLogic Portal 9.2引入了添加到门户业务服务中的新的社区框架,并为具有共同兴趣爱好的客户简化了门户成员关系、管理和门户的最终用户生成。WebLogic Portal 9.2简化了门户生命周期管理,同时改进了管理员和开发人员的生产操作。

    联邦门户

      简单地说,联邦门户是包括远程分布资源的门户。为符合WSRP而构建的portlet提供了此远程功能。这些远程资源来自称为生产者的一个或多个门户服务器,在运行时被收集和组合在被称为消费者的门户应用程序(此应用程序向用户展示联邦门户视图)中。要获得关于WSRP和WebLogic Portal的额外背景信息,请参阅在 WebLogic Portal 8.1 中使用远程 Portlet Web 服务 (WSRP)

      可将远程portlet添加到消费者门户来创建新的应用程序。图1阐释了这一概念。借助WebLogic Workshop IDE,开发人员可使用远程资源。管理员使用WebLogic Portal Administration的基于Web的工具来组合和管理联邦门户。

    Figure 1

       图1. portlet显示在提供无缝门户视图的消费者门户中。

      WebLogic Portal实现了WSRP,后者支持在运行期间将远程资源组合到新的门户应用程序中。WSRP是联邦门户的基础技术。

      联邦门户具有以下特性:

    • 分布式:Portlet被部署在企业内的远程系统上。
    • 分离:门户与其portlet不是互相依赖的。远程portlet可独立于联邦门户进行维护和部署。
    • 集成:远程portlet可相互通信和共享数据。
    • 基于标准:WebLogic Portal联邦门户构建于开放标准之上,这些开放标准包括WSRP、SOAP、WSDL、SAML和UDDI。

    联邦的好处

      联邦提供许多好处。以下是一些最常见的好处:

    • 即插即用SOA:联邦门户是即插即用面向服务架构(SOA)的真正示例。在大多数情况下,门户管理员能够定位远程portlet并将其整合到门户中,而无需开发人员帮助。这些“表示服务”由来自一个或多个生产者的portlet组成,并可由多个消费者重用,这些消费者提供了消费者和生产者之间的“多对多”关系。
    • 门户部署成本降低:门户联邦最大的好处可能是:在更新消费者联邦门户的远程portlet时,无需重新部署这些门户。远程portlet部署在独立Web应用程序中,通常是称为生产者的远程系统。当更改portlet时(例如添加或移除特性或改正错误时),引用它的远程portlet会自动反映更改。消费者门户应用程序无需重新部署。
    • 提高的版本计划灵活性:因为联邦门户中的portlet和其他服务是分布式的,所以多个团队可彼此独立地使用和部署新特性。通过Web services机制,联邦门户的开发人员仅使用由这些独立开发团队生成的软件资源。
    • 门户测试成本降低:通过定位生产者和挑选所需的portlet,门户管理员能够将新的远程portlet整合到门户中。从管理员的角度来说,这些远程portlet是经过充分测试且随时可用的。开发人员能够独立测试远程portlet,从而降低测试的复杂性。
    • 降低软件组件之间的依赖性:如果某个portlet依赖于特定软件库,则会引入必须进行管理的依赖性。对portlet或库版本进行更改可能导致与现有代码不兼容。因为远程portlet是在远程系统上开发、测试、部署和运行的,所以使用远程portlet的联邦门户没有这种依赖性。
    • 提高门户组件重用:生产者发布的portlet可由任意数量的消费者重用,只需最少量的工作且无需进行额外编码。
    • 提高互操作性:根据定义,联邦门户是松散耦合且基于标准的,这使WebLogic Portal能够使用来自第三方供应商的portlet。同样,第三方门户也可使用驻留在WebLogic门户中的portlet。

    WebLogic Portal 9.2:新特性

      现在我将检查WebLogic Portal 9.2中的新特性。涉及的主题包括:联邦书籍和页面、portlet注册表、用户配置文件传播、消费者权限、联邦拦截器和联邦工具。

    联邦书籍和页面

      因为在2003年WebLogic Portal 8.1添加了对WSRP 1.0的支持,所以SOA项目实现的数量也有所增加,客户对将更多软件资源作为服务公开和使用的需求也增加了。

      客户希望能够组合新的复合应用程序并进行无缝集成,而这要求灵活的服务基础架构。随着远程portlet数量的增加,对更好的管理结构以及提供组件之间关联性的方式(以保护松耦合)的需求也增加了。图2阐释了逻辑视图。

    Figure 2

      图2. Portlet、页面和书籍可作为WSRP资源公开。

      WebLogic Portal 9.2支持开发人员联合包含在一个或构成一本书的一组页面中的portlet组。可以一次联合几个portlet,而不是逐个进行。因为简化了管理,所以可通过页面和书籍将许多portlet作为一个组来管理。管理员不再需要明白哪些portlet是有关系的;可在页面级别上定义和联合portlet关联性。

    Portlet 注册表

      随着服务的增加,portlet、书籍和页面数量也在增加,并且需要一个更好的方式来列出、管理、发布和发现这些资源。

      WebLogic Portal 9.2添加了对任何UDDI兼容注册表的支持。UDDI注册表存储关于Web services的元数据,并支持用户搜索和发现这些服务。WebLogic Portal使用UDDI注册表为消费者提供方便的机制,以定位生产者、portlet、书籍和页面。图3阐释了发布和发现功能。

    Figure 3

       图3. WebLogic Portal能够发布和发现UDDI兼容注册表中的WSRP资源。

      人员可从门户支持每个得到部署的新portlet,从而自动在AquaLogic Service Registry中注册它们。要获得关于WebLogic Portal和AquaLogic Service Registry的更多信息,请访问产品文档。一旦不同的资源被注册,就能够搜索到它们,然后可以在企业中对这些资产进行管理。

      可以添加一套新的用户友好工具,来支持用户快速搜索和定位远程资源。通过添加注册表集成和服务总线,WebLogic Portal支持一整套SOA功能,portlet和其他资源在其中被构建、部署、注册、发现、使用、管理和监视。

      一旦发现新的远程资源,消费者门户就可以使用它们,并授予访问它们适当的权限。

    用户配置文件传播

      WebLogic Portal 8.1引入了通过定制数据传输机制在消费者和生产者之间共享数据的能力。

      定制数据传输是将数据从消费者传输到生产者的有计划的方法。WebLogic Portal 9.2简化了数据传输,并为生产者portlet提供自动化设施,以宣布其希望从消费者门户接收的内容。在运行时期间,消费者可轮流将用户配置文件属性映射到所请求的属性。属性被自动从消费者发送给生产者。

    消费者权限

      此特性支持生产者根据远程资源定制特定用户可以看到和调用的内容。这不仅仅是打开和关闭一个远程portlet,而是在运行时动态配置规则,以影响生产者行为。

      例如,开发人员能够在开发时将一个远程portlet设为“enabled”。随后,WebLogic Administration Portal中的管理员能够使用Consumer Entitlements设置规则,以根据消费者执行不同的行为。如果某一特定消费者位于高级清单中,那么它应该能够访问所有已发布的portlet。如果另一个消费者位于基本清单中,那么它应该只能访问一部分portlet。

      这提供了控制用户能够订阅的portlet的能力。根据注册信息,仅有授权的portlet是可见的,并可供消费者门户的管理员使用。这引入了与WebLogic Portal为本地部署的portlet提供的权限功能一致的远程功能。

    联邦拦截器

      联邦拦截器是WebLogic Portal 9.2中大多数现有联邦特性之一。借助于Interceptor Framework,开发人员能够完全访问Federation Lifecycle,后者定义了从生产者到消费者的联合(federation from producer to consumer)的通信和呈现过程。

      Interceptor Framework是消费者端框架,它以编程方式拦截和修改标记和与用户交互相关的WSRP消息,这些消息在生产者之间传递。图4阐明了这一概念。

    Figure 4
    图4. 拦截器可用作生产者和消费者之间的所有WSRP通信量的过滤器。

      此框架允许检查WSRP消息的内容,并根据此内容采取特定行动。开发人员也可以将数个拦截器连接起来,以完成特定任务。以下是一些拦截器最常使用的情况:

    • 处理错误:您可以使用拦截器来处理从生产者返回的错误。例如,如果一个特定生产者未注册,那么您可捕获此注册错误并按您的意愿处理它。您可将信息消息显示给用户,或者可选择自动注册此生产者。如果生产者不可用,拦截器也可以捕获I/O故障。在这种情况下,您可选择通过为用户显示信息消息或阻止针对生产者的以后的请求来处理错误。
    • 缓存标记:您可实现一个拦截器,仅缓存从生产者返回的特定标记。拦截器允许您使用您选择的任何外部缓存系统。除缓存消费者上的标记外,在某些情况下,开发人员可减少消费者和生产者之间的往返通信。WebLogic Portal提供面向portlet的开箱即用缓存,也就是说,如果需要特定行为,可使用拦截器。
    • 验证数据:拦截器可过滤用户提交的数据。如果用户数据无效,则会显示一个信息消息,或者阻止将此数据发送到生产者。
    • 替换标记:拦截器可过滤、替换或修改从生产者发送的标记数据。拦截器也可修改远程portlet的导航状态。这简化了导航链接解析的更改。
    • 修改HTTP头:拦截器可添加或移除HTTP头的元素,也可监视响应头。例如,这支持添加一个特定于客户的内部系统的定制安全令牌。

      几个客户将发现此强大特性,用它部署更复杂和功能丰富的联邦门户。要获得关于如何使用拦截器的示例,请访问WebLogic Portal 9.2在线文档

    Web services for Remote Portlets 2.0支持

      OASIS Group WSRP规范的2.0版本正处于“委员会草案”阶段,在本文发布时已快要完成,但它不会是WebLogic Portal 9.2版本的最终版。然而,WebLogic Portal 9.2将包括几个WSRP 2.0特性作为扩展。以下是WSRP 2.0最重要的特性的列表:

    WSRP 2.0功能 WebLogic Portal支持
    portlet间的协调——支持消费者设法将portlet的协调响应应用于用户交互。在portlet之间共享上下文。 在WebLogic Portal 8.1中引入——远程Portlet内通信支持
    传播——消费者和生产者数据(例如注册信息)的便携性 WebLogic Portal 9.2之后的版本中提供
    租用——指定portlet和注册的生命周期 WebLogic Portal 9.2之后的版本中提供
    安全性采用——Web services安全性的技术说明 在WebLogic Portal 8.1中引入——安全性断言标记语言 (SAML)支持

      完整的WSRP 2.0特性和功能将在WebLogic Portal 9.2之后的版本中提供。要获得关于WSRP 2.0和未来开发的最新信息,请访问OASIS集团的Web站点。

       联邦工具

      已经对WebLogic Portal 9.2基于Web的工具进行了一些实用的改进。管理员和开发人员将拥有更直观友好的环境,可以在该环境中初始化和管理联邦。一些主要的改进包括:

    • 一套增强的联邦工具
    • 简化远程生产者注册的向导
    • 用特殊图标指示库中远程资源的到场
    • 针对所有远程资源的分页功能:portlet、页面和书籍
    • 在UDDI注册表中搜索和发现远程资源的能力
    • 支持生产者上的Consumer Entitlements的额外工具
    • 测试来自控制台的远程资源的能力
    • 匹配WebLogic Server控制台的新外观
    • 跨工具应用的一致的Web导航模式

      图5显示了WebLogic Portal Administration Console。

    Figure 5
    图 5. WebLogic Portal Administration Console中改进的新联邦工具

       互操作性

      互操作性是门户联邦的主要获益之一。WebLogic Portal支持跨供应商的互操作性,它测试了各种第三方联邦生产者(包括IBM、NetUnity和Oracle)以及受WebLogic Server支持的Web应用程序生产者。WebLogic Portal 9.2也可通过WSRP(由BEA Portal .NET Application Accelerator生成)使用ASP.NET应用程序。

    联邦架构

      通过集成AquaLogic Service Bus和AquaLogic Service Registry组件(由BEA提供,用于实现服务架构),WebLogic Portal 9.2支持SOA生命周期管理。图6阐释了WebLogic Portal 9.2如何在SOA环境中工作。

    Figure 6
    图 6. WebLogic Portal可用作生产者和消费者,它还可与AquaLogic Service Bus和AquaLogic Service Registry一起使用。

      SOA生命周期管理能够提供和管理企业中的服务,从而提供企业运营和动态适应更改所需的正确的访问级别和服务质量。通过快速适应更改,企业能够变得更加敏捷和更具竞争力。这是SOA采用(SOA adoption)背后的驱动力之一。

      通过充当代理并分析消费者与生产者之间的WSRP请求,AquaLogic Service Bus提供了监视、管理和服务水平协议(SLA)支持。它还可以监视portlet服务消息中的XML,并基于环境中的规则和更改来执行转换。

      关于使用WebLogic Portal和AquaLogic Service Bus的更多信息,请参阅AquaLogic Service Bus: Interoperability with Web Services for Remote Portlets (WSRP)上的产品文档。

      WebLogic Portal 9.2添加了与任意UDDI兼容的注册表直接交互的功能。AquaLogic Service Registry可在架构阶段部署,以便在运行期间且在实现单独服务之前定义接口和策略;此流程可确保企业中的不同团队都遵从现有策略,将服务发布到注册表中。

      关于使用WebLogic Portal和AquaLogic Service Registry的更多信息,请参阅WebLogic Portal Federation文档

      AquaLogic Service Bus和AquaLogic Service Registry提供了支持面向WebLogic Portal的SOA生命周期管理所需的服务功能。

    结束语

      WebLogic Portal为WebLogic Portal 9.2版本添加了许多新特性,这些特性对于部署联邦门户非常重要。客户和合作伙伴会发现WebLogic Portal 9.2是一个功能非常强大且非常有价值的版本。另外,工程和产品团队也为WebLogic Portal 9.2而激动。请继续与WebLogic Portal团队共享反馈和请求。WebLogic Portal新闻组页面可从Dev2Dev上获得。

      关于WebLogic Portal 9.2版本的更多信息,请访问BEA的下载和在线文档页面:

    参考资料

    原文出处:http://dev2dev.bea.com/pub/a/2006/06/portal-federation-wlp9.html

     作者简介

    Alex Toussaint 是BEA Systems公司的高级产品经理。在为BEA效力的第一个5年中,他在WebLogic Portal团队中负责开发产品策略,并管理着几个领域,比如内容管理、门户联合、门户框架和新兴门户标准。

  • weblogic中影响性能的参数总结

    2006-12-30 16:01:11

  • WebLogic Server 性能调优(转自www.uml.org.cn)

    2006-12-30 15:57:42

    http://www.uml.org.cn/j2ee/200612144.htm

     

    任何在市场上成功的产品都拥有良好的性能。虽然成为象WebLogic Server这样广泛使用的产品需要具备很多特性,但性能绝对是必不可少的。

     良好的编程习惯在帮助应用运行方面起了很大的作用,但是仅有它们还是不够的。应用服务器必须能够在多种硬件和操作系统之间移植,必须具备通用性以便处理范围更广的应用类型。这就是为什么应用服务器都提供了丰富的调试“按钮”的原因,通过调整这些“按钮”,能够使服务器更适合运行环境以及应用程序。

    本文针对WebLogic讨论了其中的某些调试参数,不过并未将所有可调整的属性全部列出。此外,在将此处推荐的方法运用到产品环境之前,建议您先在测试环境中对它们测试一番。

    性能监控及瓶颈发现

    性能调试的第一步是孤立“危险区域”。性能瓶颈可以存在于整个系统的任一部分?D?D网络、数据库、客户端或应用服务器。重要的是首先确定哪个系统组件引起了性能问题,调试错了组件可能会使情况更糟。

    WebLogic Server为系统管理员提供了管理控制台和命令行工具两种方式监控系统性能。服务器端有叫作mbean的集合,用于搜集诸如线程消耗情况、资源剩余情况、缓存使用情况等信息。控制台和命令行管理器都可以从服务器将这些信息调用出来。图1的屏幕快照就显示了EJB容器中缓存的使用和剩余情况,这是控制台提供的性能监控的选项之一。

    代码分析器也是应用代码用以探测自身性能瓶颈的另一种有效的工具。有几个很好的代码分析器,如:Wily Introscope, Jprobe, Optimizelt。

    EJB 容器

    EJB容器中最昂贵的操作当然是数据库调用?D?D装载和存储实体bean。容器也因此提供了各种各样的参数以便减少数据库的访问次数。但不管怎样,除非是在特殊情况下,否则在每个bean的每次交易中,至少都得有一次装载操作和一次存储操作。这些特殊情况是:

     1. Bean是只读的。此时,bean只需在第一次访问时装载一次,从来不需要存储操作。当然,如果超出参数read-timeout-seconds的设置,bean将被再次装载。

    2. Bean 有专门的或积极的并发策略,且参数db-is-shared 设置为假。此参数在WebLogic Server 7.0中被重新命名为cache-between-transactions。参数db-is-shared 设置为假相当于参数cache-between-transactions设置为真。

    3. Bean在交易中未被修改过,此时,容器会将存储操作优化掉。

    如果不属于上述任何一种情况,则code path中的每个实体bean在每次交易时,至少会被装载和存储一次。有些特征能够减少数据库的调用或者降低数据库调用的开销,如:高速缓存技术、域(field)分组、并发策略以及紧密关联缓存(eager relationship caching)等,其中的某些特征是WebLogic Server 7.0新增的。

     高速缓存:实体bean缓存空间的大小由weblogic-ejb-jar.xml中的参数max-beans-in-cache定义。容器在交易中第一次装载bean时是从数据库调用的,此时bean也被放在缓存中。如果缓存的空间太小,有些bean就被滞留在数据库中。这样,如果不考虑前面提到的前两种特殊情况的话,这些bean在下次调用时就必须重新从数据库装载。从缓存调用bean也意味着此时不必调用setEntityContext()。如果bean的关键(主)键是组合域或者比较复杂,也能省却设置它们的时间。

    域分组:域分组是对于查找方法指定从数据库加载的域。如果实体bean与一个较大的BLOB域(比方说,一幅图像)相联系,且很少被访问,则可以定义一个将此域排除在外的域组,该域组与一个查找方法相关联,这样查找时,BLOB域即不会被装载。这种特征只对EJB2.0的bean 适用。

    并发策略:在WebLogic Server 7.0中,容器提供了四种并发控制机制。它们是独占式、数据库式、积极式和只读式。并发策略与交易进行时的隔离级别紧密相关。并发控制并不是真正意义上的提高性能的措施,它的主要目的是确保实体bean所表示的数据的一致性,该一致性由bean的部署器所强制要求。无论如何,某些控制机制使得容器处理请求的速度比其它的要快一些,但这种快速是以牺牲数据的一致性为代价的。

     最严格的并发策略是独占式,利用特殊主键对bean的访问是经过系列化的,因此每次只能有一个交易对bean进行访问。这虽然在容器内提供了很好的并发控制,但性能受到限制。在交易之间允许互为缓存的时候,这种方法很有用,但在集群环境中不能使用,此时,装载操作被优化掉,因此可能导致丧失并行性。

    数据库式的并发策略不同于数据库的并发控制。实体bean在容器中并未被锁定,允许多个交易对相同的实体bean并发操作,因此能够提高性能。当然,这样对隔离的级别也许要求较高,以便确保数据的一致性。

    积极式并发策略与数据库的并发控制也不同。不同之处在于对数据一致性的检查发生在对已设定的更新操作进行存储时而非在装载时将整行锁定。如果应用内对同一个bean访问的冲突不是很激烈的情况下,本策略比数据库式的策略要快一些,虽然两个提供了相同的数据一致性保护级别。但是在有冲突发生的时候,本策略要求调用者要重新发起调用。本特征也只对EJB 2.0 适用。

    只读式策略只能用于只读bean。Bean只在应用第一次访问时或者超出参数read-timeout-seconds所指定的值时才被装载。Bean从来不需要被存储。当基本数据改变时,也会通过read-mostly格式通知bean,从而引起重新装载。

    紧密关联缓存: 如果两个实体bean, bean A 和bean B 在CMR(容器关系管理)内关联,两个在同一个交易中被访问,且由同样的数据库调用装载,我们称为紧密关联缓存。这是WebLogic Server 7.0的新特征,同样只适用于EJB2.0。

    除了上面列出的通过优化容器内对数据库的访问从而达到性能增加的特征外,另有一些在容器之外,针对会话bean和实体bean的参数能够帮助提升性能。

    缓冲池和高速缓存是EJB容器为提高会话bean和实体bean性能所提供的主要特征。然而,这些方法并非对所有类型的bean适用。它们的消极面是对内存要求较高,虽然这不是主要的问题。缓冲池适用于无状态会话bean(SLSB),消息驱动bean(MDB)以及实体bean。一旦为SLSB和MDB设定了缓冲池的大小,这些bean的许多实例就会被创建并被放到缓冲池中,setSessionContext()/setMessageDriveContext()方法会被调用。为这些bean设置的缓冲池的大小不必超过所配置的执行线程数(事实上,要求比此数要小)。如果方法setSessionContext()要做任何开销昂贵的操作的话,此时JNDI查询已经完成,使用缓冲池中的实例方法调用将会加快速度。对实体bean来说,在完成setEntityContext()方法调用之后,缓冲池与bean的匿名实例相连(没有主键)。这些实例可以被查询操作所使用,查询方法从缓冲池中取出一个实例,为其指定一个主键,然后从数据库中装载相应的bean。

    高速缓存适用于有状态会话bean(SFSB)和实体bean。实体bean已经在前面讨论过。对于SFSB,缓存能够避免向硬盘串行化的操作。串行化到硬盘的操作非常昂贵,绝对应该避免。用于SFSB的缓存大小可以比连接到服务器的并发客户端数略微大些,这是由于仅当缓存被占用了85%以后,容器才会设法将bean滞留在数据库中待命。如果缓存大于实际所需,则容器不会通过缓存花费时间将bean待命。

    EJB容器提供了两种方法进行bean-to-bean 和 Web-tier-to-bean的调用操作:传值调用和传送地址调用。如果bean处在同一个应用之中,则缺省情况下,用的是传送地址的方法,这比传值要快一些。传送地址的方法一般不应被禁止,除非有充足的理由要强制这样做。强制使用传送地址的另一种做法是使用本地接口。在WebLogic Server 7.0中引入了另一个特征是对有状态服务使用激活(activation)。虽然这种做法在某种程度上影响了性能,但由于对内存要求较低,因此极大地改进了扩展性。如果扩展性不值得关注,可以将参数noObjectAction传送给ejbc从而关闭激活(activation)。

    JDBC

    对数据库的访问来说,调试JDBC与调试EJB容器同样重要。比方说设置连接池的大小?D?D连接池应大到足以容纳所有线程对连接的要求。如果所有对数据库的访问能够在缺省的执行队列中得以实现,则连接数应为执行队列中的线程数,比读取socket的线程(缺省执行队列中用来读取进入请求的线程)数要少。为了避免在运行期间对连接进行创建和删除,可在初始时即将连接池设置为其最大容量。如果可能的话,应确保参数TestConnectionsOnReserve被设置为假(false,这是缺省设置)。如果此参数设置为真(true),则在连接被分配给调用者之前,都要经过测试,这会额外要求与数据库的反复连接。

    另一个重要的参数是PreparedStatementCacheSize。每个连接都为宏语句设一个静态的缓存,大小由JDBC连接池配置时指定。缓存是静态的,时刻牢记这一点非常重要。这意味着如果缓存的大小是n的话,则只有放在缓存中的前n条语句得到执行。确保昂贵的SQL语句享受到缓存的方法是用一个启动类将这些语句存放到缓存中。尽管缓存技术从很大程度上改进了性能,但也不能盲目使用它。如果数据库的格式有了变化,那么在不重新启动服务器的情况下,无法使缓存中的语句失效或者是用新的进行替换。当然,缓存中的语句会使数据库中的光标得以保留。

    对于WebLogic Server 7.0来说,由于jDriver性能的改进已使其速度远远快于Oracle的?C驱动程序,尤其对于要完成大量SELECT操作的应用来说就更是如此。这可以从HP提交的利用WebLogic Server 7.0 Beta版的两份Ecperf结果得到证明(http://ecperf.theserverside.com/ecperf/index.jsp?page=results/top_ten_price_performance)。

    JMS

    JMS子系统提供了很多的调试参数。JMS消息是由称为JMSDispatcher的独立执行队列处理的。因此,JMS子系统既不会由于运行在缺省或者其它执行队列中的应用因争夺资源而导致“营养匮乏”,反过来也不会抢夺其它应用的资源。对JMS来说,大多数的调试参数都是在服务的质量上进行折衷处理。如,利用文件式持续性目的地(file-persistent destnation)禁止同步写操作(通过设置特性: -Dweblogic.JMSFileStore.SynchronousWritesEnabled =false)以后会引起性能急剧提高,但同时也会冒着丢失消息或者重复接收消息的风险。类似地,利用多点传送发送消息会提升性能,同时也会有消息半途丢失的危险。

    消息确认间隔不应设置得过短?D?D发送确认的比率越大,处理消息的速度可能会越慢。同时,如果设置得过大,则意味着系统发生故障时,消息会丢失或者被重复发送。

    一般说来,应在单个服务器上对多个JMS目的地进行配置,而不是将它们分散在多个JMS服务器,除非不再需要扩展。

    关闭消息页面调度(paging)可能会提高性能,但会影响可扩展性。如果打开消息页面调度(paging),则需要额外的I/O操作以便将消息串行化到硬盘,在必要的时候再读进来,但同时也降低了对内存的要求。

    一般来说,异步过程比同步过程更好操作,更易于调节。

    Web容器

    Web层在应用中更多的是用来生成表达逻辑。广泛使用的体系结构是从应用层读取数据,然后使用servlet和JSP生成动态内容,其中应用层一般由EJB组成。在这种结构中,servlet 和JSP保留对EJB的引用,以防它们与数据库或数据源直接对话。将这些引用保存起来是个不错的主意。如果JSP和servlet没有和EJB部署在同一台应用服务器上,则利用JNDI进行查询的费用是很昂贵的。

    JSP缓存标记符可以用于存储JSP页面内的数据。这些标记符都支持对缓存的输入和输出。对缓存的输出涉及到标记符内的代码所生成的内容,对缓存的输入涉及到标记符内的代码对变量的赋值。如果不希望Web层频繁变化,则可以通过将ServletReloadCheckSecs 设置为-1,从而关闭自动装载(auto-reloading)功能。使用这种方法以后,服务器将不再轮询Web层是否有变化,如果JSP和servlet的数量很多,则效果是非常明显的。

    这里也建议不要在HTTP会话中储存过多的信息。如果信息是必须的,可以考虑使用有状态会话bean来替代。

    JVM调试

    如今的大多数JVM具有自主调节功能,因为它们能够探测到代码中的危险区域并对它们进行优化。开发和部署人员能够考虑的调试参数大概就是堆设置了。设置这些并没有一般的规则。JVM一般堆空间,按新空间或保留空间一般设置为整个堆空间的三分之一或一半组织。整个堆空间不能指定得过大以致于无法支持并发的内存垃圾回收(GC)处理。在这种设置环境中,如果堆太大的话,垃圾回收的间隔应设为一分钟或更长。最后,需要引起注意的是这些设置在很大程度上依赖于部署在服务器上的应用使用内存的模式。有关调试JVM的其它信息可以参考:

    http://edocs.bea.com/wls/docs70/perform/JVMTuning.html1104200。

    服务器调试

    除了由各个子系统提供的调试参数以外,还有适用于服务器的参数能够帮助提升性能。其中最重要的是配置线程数和执行队列数。增加线程数并非总能奏效,仅当下列情况成立时再考虑使用这种方法:预定的吞吐量没有达到;等待队列(未开始处理的请求)过长;CPU仍有剩余。当然,这样做并不一定能改善性能。CPU使用率低可能是由于对服务器的其它资源竞争所致,如,没有足够的JDBC连接。当改变线程数时应考虑到这些类似的因素。

    在WebLogic Server 7.0中,提供了配置多个执行队列的功能,并且能够在部署中定义处理特殊的EJB或JSP/servlet请求的执行队列。要做到这些,只要在运行weblogic.ejbc时将标志-dispatchPolicy <队列名称> 传送给bean 即可。对于JSP/servlet,可将设置Web应用的weblogic部署描述符中初始化参数(init-param) wl-dispatch-policy的值设为执行队列的名字即可。有时应用中的某些bean/JSP对操作的响应时间比其它的要长,此时,可以对这些bean/JSP设置单独的执行队列。至于队列的大小,要达到最好的性能,还取决于经验。

    另一个比较大的问题是决定在何种情况下应该使用WebLogic性能包(http://e-docs.bea.com/wls/docs70/perform/WLSTuning.html - 1112119)。如果socket数不太多(每个服务器上都有一个socket用于客户端JVM的远程方法调用连接),而且总是忙于读取从客户端发送过来的请求数据,那么此时使用性能包恐怕不会有明显的改进。也有可能不用性能包会导致相似或更好的结果,这取决于JVM在处理网络I/O时的具体实现。

    Socket读取线程取自缺省执行队列。在Windows 环境下,每个CPU有两个socket读取线程,在solaris环境下,共有三个socket用于本地输入输出(native I/O)。对于Java 输入输出(I/O),读取线程数由配置文件config.xml中的参数PercentSocketReaderThreads 进行设置。它的缺省值是33%, 上限是50%,这是显而易见的,因为如果没有线程用于处理请求,则同样不会有更多的读取线程啦。对于Java I/O,应使读取线程数尽量接近客户端连接数,因为在等待请求时,Java I/O会阻塞。这也是为什么当客户端的连接数增加时,线程数不能一直同等增加的原因。

    结论

    我们上面只讨论了调试服务器的部分方法。需要记住的是,一个设计蹩脚,编写欠佳的应用,通常都不会有好的性能表现,无论对服务器及其参数如何调试。贯穿应用开发周期的各个阶段?D?D从设计到部署,性能始终应该是考虑的关键因素。经常发生的情况是性能被放在了功能之后,等到发现了问题再去修改,已经很困难了。有关WebLogic Server 性能调试的其它信息可以参考:http://e-docs.bea.com/wls/docs70/perform/index.html。

  • WebLogic管理精华

    2006-12-30 15:54:27

    转载自BEA中文网

    http://dev2dev.bea.com.cn/bbsdoc/20050974.html

     

     

    日常管理 WebLogic Platform 8.1 永不过期的开发版license

    下载地址为:

    http://dev2dev.bea.com.cn/bbs/servlet/D2DServlet/download/81-8992-44196-240/license.bea

     

    使用方式:

    替换c:\bea目录下的这个文件,这样就可以使WebLogic Platform用不过期

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=8992&tstart=0&quint=true

    如何远程启动WebLogic服务?

    用telnet远程控制服务器,远程启动WEBLOGIC服务,启动后关闭telnet,WebLogic服务也跟着停止,这是因为使用telnet启动的进程会随着telnet进程的关闭而关闭。所以我们可以使用一些UNIX下的命令来做到不关闭。

     

    使用如下命令:

    nohup startWeblogic.sh&

     

    如果想要监控标准输出可以使用:

    tail -f nohup.out

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=7709&tstart=0&quint=true

     

    控制台左边的树结构看不见?

    这是因为浏览器没有安装合适版本的JRE插件来支持Applet。

    可以到http://java.sun.com/products/plugin/ 下载相应浏览器的插件来解决这个问题。

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=5233&tstart=0&quint=true

    WebLogic 配置出来的各种域有什么区别?

    请看这个链接中的Table 16-1 Configuration Template Summary ,说的很明白
    http://e-docs.bea.com/platform/docs81/confgwiz/tempref.html

    Table 16-1 Configuration Template Summary 

    Template

    Required WebLogic Platform Component

    Filename

    Descrīption

    Avitek Medical Records Sample Domain

    WebLogic Server

    medrec.jar

    Creates the Avitek Medical Records domain outside the installed kit. This domain is a WebLogic Server sample application suite that concisely demonstrates all aspects of the J2EE platform.

    Basic WebLogic Integration Domain

    WebLogic Integration,

    WebLogic Workshop,

    WebLogic Server

    wli.jar

    Creates a domain that supports the development of WebLogic Integration solutions.

    Note: To create a domain that supports the development of WebLogic Server Process Edition solutions, use the Basic WebLogic Integration Domain template. If you have an existing WebLogic Server-based domain, you can extend it to include the resources required for WebLogic Server Process Edition by using the WebLogic Integration Extension Template.

    Basic WebLogic Platform Domain

    WebLogic Platform (all components must be installed)

    platform.jar

    Creates a domain that supports the development of applications using all WebLogic Platform components.

    Basic WebLogic Portal Domain

    WebLogic Portal,

    WebLogic Workshop,

    WebLogic Server

    wlp.jar

    Creates a domain that supports the development of WebLogic Portal solutions.

    Basic WebLogic Server Domain

    WebLogic Server

    wls.jar

    Creates a simple WebLogic Server domain without any sample applications.

    Basic WebLogic Workshop Domain

    WebLogic Workshop,

    WebLogic Server

    wlw.jar

    Creates a domain that supports the development of WebLogic Workshop solutions.

    WebLogic Server Examples Domain

    WebLogic Server

    examples.jar

    Creates the WebLogic Server Examples domain outside the installed kit. This domain contains a collection of examples that illustrate best practices for coding individual J2EE APIs.


     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=9188&tstart=0&quint=true

     

    Too many open files错误的处理

    在有些Linux下由于操作系统的限制,单一进程可以打开的文件数有限制,引起WebLogic报告错误,解决这问题需要编译内核并且调节一些限制参数。

     

    在Linux内核2.4.x中需要修改源代码,然后重新编译内核才生效。编辑Linux内核源代码中的 include/linux/fs.h文件,将 NR_FILE 由8192改为65536,将NR_RESERVED_FILES 由10 改为 128。编辑fs/inode.c 文件将MAX_INODE 由16384改为262144。一般情况下,系统最大打开文件数比较合理的设置为每4M物理内存256,比如256M内存可以设为16384,而最大的使用的i节点的数目应该是最大打开文件数目的3倍到4倍。另外,对每个进程的设置:

    ulimit -n 4096 将每个进程可以打开的文件数目加大到4096,缺省为1024

    ulimit -m 4096 限制每个进程使用的内存数。

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=2461&tstart=0&quint=true

     

    Apache2和weblogic7实现虚拟主机

    选择apache2,是因为目前wls7只支持apache2的结合.

     

    1.首先,正确安装apache2,这里我们假设安装在C:\apache group,安装完毕,需要测试apache2是否支持动态加载模块功能,这样测试,到命令

     

    提示符下运行:

    c:\>apache group\apache2\bin\apache -l

    如果列出:

    mod_so.c

    则表示支持,然后将本篇文章附件中的mod_wl_20.so拷贝到apache group\apache2\modules下面,运行:

    c:\>apache group\apache2\bin\apache -t

    如果输出:

    Syntax Ok

    表示WebLogic Server plug-in安装成功。

     

    2.正确安装weblogic7.0。这里我们假设wls7的安装路径是:c:\bea。然后用域配置向导配置一个域,我们假设域

    的名称为amjn,路径是c:\bea\user_projects\amjn,然后在amjn下面分别建立两个站点web1,web2,修改

     

    c:\bea\user_projects\amjn\config.xml文件,在

    <Application Deployed="true" Name="DefaultWebApp"

    Path=".\applications" StagedTargets="" TwoPhase="false">

    <WebAppComponent Name="DefaultWebApp" Targets="myserver" URI="DefaultWebApp"/>

    </Application>

    下面添加:

    <Application Deployed="true" Name="web1" Path=".\applications\web1"

    StagedTargets="" TwoPhase="false">

    <WebAppComponent Name="web1" URI="web1" VirtualHosts="web1_vh"/>

    </Application>

    <Application Deployed="true" Name="web2" Path=".\applications\web2"

    StagedTargets="" TwoPhase="false">

    <WebAppComponent Name="web2" Targets="myserver" URI="web2" VirtualHosts="web2_vh"/>

    </Application>

    在文件最下面的

    </Domain>

    的上面添加

    <VirtualHost DefaultWebApp="web1" Name="web1_vh" Targets="myserver" VirtualHostNames="www.web1.com"/>

    <VirtualHost DefaultWebApp="web2" Name="web2_vh" Targets="myserver" VirtualHostNames="www.web2.com"/>

    ,然后重新启动运行\amjn\startWebLogic.cmd,一定要运行正常。到这里,weblogic算是配置完成了。

     

    3.现在开始配置apache多个虚拟主机,首先我们先打开c:\winnt\system32\drivers\etc\hosts文件,在其中添加:

    10.1.3.30 www.web1.com

    10.1.3.30 www.web2.com

    这里面的10.1.3.30是你的weblogic服务器绑定的ip,然后打开apache2\conf\httpd.conf文件,在174行,注意是174行加入如下语句:

    #WebLogic Server Proxy Settings-------该行是174行

    LoadModule weblogic_module modules/mod_wl_20.so

    <IfModule mod_weblogic.c>

    WebLogicHost www.synnex-china.com

    WebLogicPort 7001

    MatchExpression *.jsp

    MatchExpression *.do

    </IfModule>

    然后修改httpd.conf文件中的Listen:80为Listen:10.1.3.30:80,在文件section 3部分添加:

    NameVirtualHost 10.1.3.30

    <VirtualHost 10.1.3.30>

    ServerName www.web1.com

    DocumentRoot "c:/bea/user_projects/amjn/applications/web1"

    ErrorLog logs/web1.com.log

    </VirtualHost>

     

    <VirtualHost 10.1.3.30>

    ServerName www.web2.com

    DocumentRoot "c:/bea/user_projects/amjn/applications/web2"

    ErrorLog logs/web2.com.log

    </VirtualHost>

    启动apache,如果没有问题(可以通过logs/error.log查看),那就一切ok了

     

    4.现在你可以分别敲入www.web1.com/index.jsp,访问的将是web1/index.jsp,敲入www.web2.com/index.jsp访问的将是web2/index.jsp

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=6326&tstart=0&quint=true

    如何限制公网用户访问WebLogic的控制台呢?

    我们的weblogic(版本6.1)应用部署在内部网上,通过防火墙映射到公网上,但公网用户通过键入域名:www.xxx.com/console,就可进入weblogic的登陆页面,用户可猜测管理员的密码,如何屏蔽公网用户对weblogic控制台的访问呢?

     

    方法1:

    在控制台上点击左边的你那个domain,将Console Enabled这个选项去掉,这样就完全不能使用console了

    方法2:

    将“console”改名,改“Console Context Path”的“console”为一个希奇古怪的名字就可以了

    方法3:

    不要给WebLogic公网ip,通过一个有公网ip的apache等proxy来访问WebLogic

    方法4:

    启动Administration Port

    方法5:

    应用不发布在Admin Server上,Admin Serve在外网不可见

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=2230

     

    开机自动启动oracle和weblogic

    我的机器是5L,oracle9i,weblogic6.1,HTTPServer
    由于给别人装的机器,对方水平有限,为了省心,还是让系统起来自动运行各项应用比较好:)
    首先自动启动oracle9i,9i装在oracle文件系统下,在/oracle下建立文件startdb,
    文件内容
    echo "begin to start oracle"
    lsnrctl start
    sqlplus /nolog <<EOF
    connect /as sysdba
    startup
    exit
    exit
    echo "oracle have started"
    给startdb执行权限
    自动关闭oracle9i,在/oracle下建立文件stopdb
    sqlplus /nolog <<EOF
    connect /as sysdba
    shutdown immediate
    好了启动和关闭oracle脚本完成还要加到系统的启动和关闭文件里,另外还要在启动oracle后启动weblogic
    在/etc下建立文件rc.startdb,脚本如下

    su - oracle "-c /oracle/startdb"    #启动oracle
    cd /weblogic/wlserver6.1/config/mydomain  #转到weblogic启动目录,必须
    ./startWebLogic.sh  #启动weblogic
    给文件执行权限
    注意由于weblogic在启动后如果用户退出telnet 就自动关闭,所以要把weblogic放在后台执行,所以在startWebLogic.sh文件中启动weblogic的命令行改为可以在后台运行,用 nohup (启动命令行) >/home/weblogic.log &
    把weblogic的运行信息存到/home/weblogic.log文件中

    下面要把启动信息放到inittab中,加入一行
    startdb:2345678:wait:/etc/rc.startdb
    这样系统启动后会自动启动oracle9i


    系统关机自动关闭oracle9i
    在/etc下建立脚本文件rc.stopdb
    su - oracle "-c /oracle/stopdb"
    给执行权限
    由于5L中安装完成后没有/etc/rc.shutdown文件,需要手工创建一个
    内容如下
    #!/bin/ksh 
    rc.stopdb
    给执行权限
    这样当系统关机时会自动寻找rc.shutdown并执行,系统可以自动关闭oracle9i

    当然可以把一些命令行直接写入inittab或rc.shutdown中,看自己的喜好了:)

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=8415&tstart=25&quint=true

     

    如何测试虚拟主机

    在本机配置了虚拟主机,没有DNS Server,如何进行测试呢?

    C:\WINNT\system32\drivers\etc\hosts加入一行:127.0.0.1 test.project.com.cn

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=9776&tstart=25&quint=true

     

    WebLogic的Startup Class应该放在那个目录里

    WebLogic在启动的时候可以指定Startup Class,它在任何一个应用的类被加载之前调用,所以应该加到启动时的系统类路径下,可以修改startWebLogic.cmd或commEnv.cmd文件相应的CLASSPATH部分,加入Startup Class的类路径。

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=9119&tstart=25&quint=true

     

    如何停止WebLogic服务?

    直接杀死进程不是标准的做法,应该使用如下Java命令:

    java -classpath weblogic.jar;%CLASSPATH% weblogic.Admin -url <host_name>:<port_number> SHUTDOWN -username <system_user_name> -password <system_user_password>

    例如:

    java -classpath weblogic.jar;%CLASSPATH% weblogic.Admin -url 192.168.0.1:7001

    SHUTDOWN -username system -password password

    其中如果SHUTDOWN管不掉,可以使用FORCESHUTDOWN代替SHUTDOWN来强制关掉服务器。

     

    另外也可以直接使用stopWebLogic.cmd。

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=5519&tstart=25&quint=true

     


    应用管理 JNDI里面加和不加java:comp/env/前缀有什么区别?

    java:comp/env是标准的J2EE环境查找规则,使用这种方式必须做一次环境名到JNDI名的映射,这种隔离使得在写程序时不必关注真正的JNDI名字,其实说白了跟把JNDI名放到配置文件里是一样的,用法如下:

    如把java:comp/env/my/datasource映射到my.ora.dataource

    web.xml
    <resource-ref>
    <res-ref-name>my/datasource</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>CONTAINER<res-auth>
    </resource-ref>

    weblogic.xml
    <reference-descrīptor>
    <resource-descrīption>
    <res-ref-name>my/datasource</res-ref-name>
    <jndi-name>my.ora.dataource</jndi-name>

    ………………….

    而不使用这个前缀的,其实就是直接的JNDI名

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=17074&tstart=0&quint=true

     

    如何更改默认打开主页?如何设置虚拟目录?

    设置默认打开主页:

    web.xml增加
    <welcome-file-list>
    <welcome-file>yourfile</welcome-file>
    </welcome-file-list>

     

    虚拟目录的配置方法:
    在weblogic.xml中添加如下的类似配置
       <virtual-directory-mapping>
         <local-path>c:/usr/common_jsps.jar</local-path>
         <url-pattern>*.jsp</url-pattern>
       </virtual-directory-mapping>

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=16333&tstart=0&quint=true

     

    WebLogic Builder使用简介

    在DEV2DEV论坛上有网友会问类似于这样的问题“如何为EJB写那些部署描述文件如ejb-jar.xml以及WebLogic-ejb- jar.xml呢?”,对初学EJB的朋友来说,是一个比较困难的问题,如果不想手写的话,可以采用BEA提供的WebLogic Builder工具或是JBuilder等工具来自动生成。本文就WebLogic Builder的使用进行一个简单的介绍,权且当一个入门的指引,同时欢迎各位朋友就你的经验对这篇文章进行补充完善。使用步骤如下:

     

    一、准备。
    例子就用WebLogic安装完后的example中statelessSession EJB的例子,给个路径参考
    C: \bea\weblogic700\samples\server\src\examples\ejb20\basic\statelessSession  将这个目录下的.java文件全部拷贝出来放到一个临时目录中比如C:\temp\WebLogic_Builder_Test来做这个实验,拷贝的文件有Client.java,Trader.java,TraderBean.java,TradeResult.java, TraderHome.java。

     

    二、对java原文件进行编译
    命令行中进入C:\temp\WebLogic_Builder_Test,键入 javac -d . *.java,

     

    三、打jar包
    命令行中,C:\temp\WebLogic_Builder_Test目录下,键入jar -cvf test.jar *.*,生成test.jar包。

     

    四、打开WebLogic Builder工具,选择并打开我们在步骤三中创建的test.jar包,这时WebLogic Builder给出一个提示“Unable to locate deployment descrīptors. C:\temp\WebLogic_Builder_Test\test.jar. Would you like new descrīptors created for you?”,这意思明白了吧,WebLogic Builder要为你创建基本的部署描述符文件了,当然点击是咯,然后选择保存,这样你的C:\temp\WebLogic_Builder_Test目录下的test.jar文件就有那两个部署描述文件了,可以通过WebLogic Builder工具中的View-->XML Source进行查看。

     

    恭喜你,对WebLogic Builder这个工具的使用入门了,至于该工具的其它的一些使用功能比如BEAN属性配置、server部署什么的,就请大家自己研究吧!^Q^

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=2683

     

    WebLogic部署应用的方式简明列表

    1、WebLogic中应用可分三种,分别对应不同的描述文件及扩展名或目录结构:

    (1)*.JAR: 是EJB的压缩包(有3个描述文件ejb-jar.xml,WEBLOGIC*.0-ejb-jar.xml,WEBLOGIC*.0-cmp-rdbms-jar.xml)

    (2)*.WAR: 是只包含JSP和SERVLET的WEB APPLICATION压缩包(有2个描述文件web.xml,weblogic.xml)

    (3)*.EAR: 是包含EJB和WEB APPLICATION 的J2EE Enterprise Application压缩包(有1 个描述文件,application.xml)

    注意:它们不能混用,如WEB APPLICATOIN不能打包成.EAR文件。

     

    2、WebLogic的应用用两种发布方式:

    (1)以目录形式存放在WEBLOGIC的APPLICATIONS目录下,适用于开发阶段

    (2)以一个压缩包形式存放在WEBLOGIC的APPLICATIONS目录下,适用于运行阶段,可用JAR 打包,如D:\test >jar cf testwar.war *

    把TEST目录下的所有文件打包成一个testwar.war文件。

     

    3、WebLogic应用的布置方式有2种

    (1)静态布置:即把应用在CONFIG.XML中登记,可通过WEBLOGIC的控制台进行添加,WEBLOGIC会自动把该应用对应的压缩包拷到APPLICAITONS目录下,如果对该应用修改,需要重新布置才行。

    (2)动态布置:没有在config.xml中登记,可直接把压缩包或目录拷到APPLICATIONS目录下,WebLogic会自动检测到. WebLogic每次启动时会自动对APPLICATIONS目录下没有进行静态布置的应用,进行动态布置。

     

    4、一个例子:

    如果一个应用中有EJB,JSP,SERVLET,其布置步骤如下:

    (1)生成EJB的JAR文件,最好一个JAR文件对应一个EJB

    (2)生成WEB APPLICATION的WAR文件,在web.xml,weblogic.xml中登记,配置SERVLET,JSP等。

    (3)创建一个application.xml文件,设置该应用的属性.把application.xml,*.JAR, *.WAR,打包成一个*.EAR

    (4)WebLogic的控制台中登记该应用或把该EAR文件拷到application目录下。到此处就完成了部署。

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=8766&tstart=25&quint=true

     

    WebLogic如何设置session超时时间

    1 web.xml

    设置WEB应用程序描述符web.xml里的<session-timeout>元素。这个值以分钟为
    单位,并覆盖weblogic.xml中的TimeoutSecs属性
      <session-config>
        <session-timeout>54</session-timeout>
      </session-config>
    此例表示Session将在54分钟后过期
    当<session-timeout>设置为-2,表示将使用在weblogic.xml中设置的
    TimeoutSecs这个属性值。
    当<session-timeout>设置为-1,表示Session将永不过期,而忽略在
    weblogic.xml中设置的TimeoutSecs属性值。
    该属性值可以通过console控制台来设置

    2 weblogic.xml

    设置WebLogic特有部署描述符weblogic.xml的<session-descrīptor>元素的
    TimeoutSecs属性。这个值以秒为单位
    <session-descrīptor>
       <session-param>
          <param-name>TimeoutSecs</param-name>
          <param-value>3600</param-value>
       </session-param>
    </session-descrīptor>
    默认值是3600秒

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=1972&tstart=25&quint=true


    监控调优 理解JVM的垃圾收集机制

    简述

    GC即垃圾收集机制是指JVM用于释放那些不再使用的对象所占用的内存。java语言并不要求JVM有GC,也没有规定GC如何工作。不过常用的JVM都有GC,而且大多数GC都使用类似的算法管理内存和执行收集操作。

     

    在充分理解了垃圾收集算法和执行过程后,才能有效的优化它的性能。有些垃圾收集专用于特殊的应用程序。比如,实时应用程序主要是为了避免垃圾收集中断,而大多数OLTP应用程序则注重整体效率。理解了应用程序的工作负荷和JVM支持的垃圾收集算法,便可以进行优化配置垃圾收集器。

     

    垃圾收集的目的在于清除不再使用的对象。GC通过确定对象是否被活动对象引用来确定是否收集该对象。GC首先要判断该对象时候可以收集。两种常用的方法是引用计数和对象引用遍历。引用计数存储对特定对象的所有引用数,也就是说,当应用程序创建引用以及引用超出范围时,JVM必须适当增减引用数。当某对象的引用数为0时,便可以进行垃圾收集。

     

    早期的JVM使用引用计数,现在大多数JVM采用对象引用遍历。对象引用遍历从一组对象开始,沿着整个对象图上的每条链接,递归确定可到达(reachable)的对象。如果某对象不能从这些根对象的一个(至少一个)到达,则将它作为垃圾收集。在对象遍历阶段,GC必须记住哪些对象可以到达,以便删除不可到达的对象,这称为标记(marking)对象。

     

    下一步,GC要删除不可到达的对象。删除时,有些GC只是简单的扫描堆栈,删除未标记的对象,并释放它们的内存以生成新的对象,这叫做清除(sweeping)。这种方法的问题在于内存会分成好多小段,而它们不足以用于新的对象,但是组合起来却很大。因此,许多GC可以重新组织内存中的对象,并进行压缩(compact),形成可利用的空间。

     

    为此,GC需要停止其他的活动活动。这种方法意味着所有与应用程序相关的工作停止,只有GC运行。结果,在响应期间增减了许多混杂请求。另外,更复杂的GC不断增加或同时运行以减少或者清除应用程序的中断。有的GC使用单线程完成这项工作,有的则采用多线程以增加效率。

     

    下面列举一些JVM使用的GC

    标记-清除收集器:这种收集器首先遍历对象图并标记可到达的对象,然后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。

    标记-压缩收集器:有时也叫标记-清除-压缩收集器,与标记-清除收集器有相同的标记阶段。在第二阶段,则把标记对象复制到堆栈的新域中以便压缩堆栈。这种收集器也停止其他操作。

    复制收集器这种收集器将堆栈分为两个域,常称为半空间。每次仅使用一半的空间,JVM生成的新对象则放在另一半空间中。GC运行时,它把可到达对象复制到另一半空间,从而压缩了堆栈。这种方法适用于短生存期的对象,持续复制长生存期的对象则导致效率降低。

    增量收集器增量收集器把堆栈分为多个域,每次仅从一个域收集垃圾。这会造成较小的应用程序中断。有多种方法可以定义实际的GC。

    分代收集器  这种收集器把堆栈分为两个或多个域,用以存放不同寿命的对象。JVM生成的新对象一般放在其中的某个域中。过一段时间,继续存在的对象将获得使用期并转入更长寿命的域中。分代收集器对不同的域使用不同的算法以优化性能。

    并发收集器  并发收集器与应用程序同时运行。这些收集器在某点上一般都不得不停止其他操作以完成特定的任务,但是因为其他应用程序可进行其他的后台操作,所以中断其他处理的实际时间大大降低。

    并行收集器  并行收集器使用某种传统的算法并使用多线程并行的执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序的可扩展性。

    Sun Hotspot 1.4.1 JVM堆大小的调整

    Sun Hotspot 1.4.1使用分代收集器,它把堆分为三个主要的域:新域、旧域以及永久域。JVM生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环后,便获得使用期并进入旧域。在永久域中JVM则存储class和method对象。就配置而言,永久域是一个独立域并且不认为是堆的一部分。下面介绍如何控制这些域的大小。

    可使用-Xms和-Xmx控制整个堆的原始大小或最大值。比如,下面的命令是把初始大小设置为128M:

     java –Xms128m –Xmx256m

    为控制新域的大小,可使用-XX:NewRatio设置新域在堆中所占的比例。比如下面的命令把整个堆设置成128m,新域比率设置成3,即新域与旧域比例为1:3,新域为堆的1/4或32M:

    java –Xms128m –Xmx128m –XX:NewRatio =3

    可使用-XX:NewSize和-XX:MaxNewsize设置新域的初始值和最大值。比如,下面的命令把新域的初始值和最大值设置成64m:

     java –Xms256m –Xmx256m –Xmn64m

    一般不把永久域当作堆的一部分。永久域默认大小为4m。运行程序时,JVM会调整永久域的大小以满足需要。每次调整时,JVM会对堆进行一次完全的垃圾收集。使用-XX:MaxPerSize标志来增加永久域搭大小。在WebLogic Server应用程序加载较多类时,经常需要增加永久域的最大值。当JVM加载类时,永久域中的对象急剧增加,从而使JVM不断调整永久域大小。为了避免调整,可使用-XX:PerSize标志设置初始值。比如,下面把永久域初始值设置成32m,最大值设置成64m。

    java –Xms512m –Xmx512m –Xmn128m –XX:PermSize=32m –XX:MaxPermSize=64m

    默认状态下,HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden,用于生成新的对象。另两部分称为救助空间,当Eden充满时,收集器停止应用程序,把所有可到达对象复制到当前的from救助空间,一旦当前的from救助空间充满,收集器则把可到达对象复制到当前的to救助空间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制,直到它们获得使用期并转入旧域。

    使用-XX:SurvivorRatio可控制新域子空间的大小。同NewRation一样,SurvivorRation规定某救助域与Eden空间的比值。比如,以下命令把新域设置成64m,Eden占32m,每个救助域各占16m:

    java –Xms256m –Xmx256m –Xmn64m –XX:SurvivorRation=2

    如前所述,默认状态下HotSpot对新域使用复制收集器,对旧域使用标记-清除-压缩收集器。在新域中使用复制收集器有很多意义,因为应用程序生成的大部分对象是短寿命的。理想状态下,所有过渡对象在移出Eden空间时将被收集。如果能够这样的话,并且移出Eden空间的对象是长寿命的,那么理论上可以立即把它们移进旧域,避免在救助空间反复复制。
    但是,应用程序不能适合这种理想状态,因为它们有一小部分中长寿命的对象。最好是保持这些中长寿命的对象并放在新域中,因为复制小部分的对象总比压缩旧域廉价。

    为控制新域中对象的复制,可用-XX:TargetSurvivorRatio控制救助空间的比例。该值是一个百分比,默认值是50。当较大的堆栈使用较低的sruvivorratio时,应增加该值到80至90,以更好利用救助空间。

    用-XX:maxtenuring threshold可控制上限。为放置所有的复制全部发生以及希望对象从eden扩展到旧域,可以把MaxTenuring Threshold设置成0。设置完成后,实际上就不再使用救助空间了,因此应把SurvivorRatio设成最大值以最大化Eden空间,设置如下:

    java … -XX:MaxTenuringThreshold=0 –XX:SurvivorRatio=5000

     

    从JVM中获取信息以助于调整方案

    -verbose.gc开关可显示GC的操作内容。打开它,可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。

    打开-xx:+ printgcdetails开关,可以详细了解GC中的变化。

    打开-XX: + PrintGCTimeStamps开关,可以了解这些垃圾收集发生的时间,自JVM启动以后以秒计量。

    最后,通过-xx: + PrintHeapAtGC开关了解堆的更详细的信息。

    为了了解新域的情况,可以通过-XX:=PrintTenuringDistribution开关了解获得使用期的对象权。

    BEA JRockit JVM的使用

    Bea WebLogic 8.1使用的新的JVM用于Intel平台。在Bea安装完毕的目录下可以看到有一个类似于jrockit81sp1_141_03的文件夹。这就是Bea新JVM所在目录。

    不同于HotSpot把Java字节码编译成本地码,它预先编译成类。JRockit还提供了更细致的功能用以观察JVM的运行状态,主要是独立的GUI控制台或者WebLogic Server控制台。Bea JRockit JVM支持4种垃圾收集器:

    分代复制收集器:它与默认的分代收集器工作策略类似。对象在新域中分配,即JRockit文档中的nursery。这种收集器最适合单CPU机上小型堆操作。

    单空间并发收集器:该收集器使用完整堆,并与背景线程共同工作。尽管这种收集器可以消除中断,但是收集器需花费较长的时间寻找死对象,而且处理应用程序时收集器经常运行。如果处理器不能应付应用程序产生的垃圾,它会中断应用程序并关闭收集。

    分代并发收集器:这种收集器在护理域使用排它复制收集器,在旧域中则使用并发收集器。由于它比单空间共同发生收集器中断频繁,因此它需要较少的内存,应用程序的运行效率也较高,注意,过小的护理域可以导致大量的临时对象被扩展到旧域中。这会造成收集器超负荷运作,甚至采用排它性工作方式完成收集。

    并行收集器:该收集器也停止其他进程的工作,但使用多线程以加速收集进程。尽管它比其他的收集器易于引起长时间的中断,但一般能更好的利用内存,程序效率也较高。


    默认状态下,JRockit使用分代并发收集器。要改变收集器,可使用-Xgc:<gc_name>,对应四个收集器分别为gencopy, singlecon,gencon以及parallel。可使用-Xms和-Xmx设置堆的初始大小和最大值。要设置护理域,则使用-Xns:

    java –jrockit –Xms512m –Xmx512m –Xgc:gencon –Xns128m…

    尽管JRockit支持-verbose:gc开关,但它输出的信息会因收集器的不同而异。JRockit还支持memory、load和codegen的输出。

     

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=124&threadID=19031&tstart=0

     

    WebLogic Server Hang产生的一般原因

    系统内存不足

    • 系统CPU忙,系统文件描述符数目不足,线程死锁,JVM有GC方面的bug,对于一些特定的情况可以使用truss命令跟踪系统调用来进行分析。可以打开JVM的gc log,在java命令行上加上-verbose:gc,GC的log输出在java进程的标准输出里,在hp的JVM上,可以通过在java命令行上加-Xverbosegc:file=gcfilename来将gc log写到指定的文件其输出类似:[GC 15639K->13700K(65280K), 0.0068439 secs]。解决办法是调整JVM的内存设置和gc算法,升级jvm或是os patch。
    • 出现OutOfMemoryError或是观察到内存吃紧,操作系统本身的剩余内存,通过top或是vmstat观察,操作系统的swap区,Swap区太小可能导致编译jsp时报“Not enough space”的错,操作系统kernel参数中maxsize的大小,如果观测到数据库连接池里的连接泄漏,极可能是内存泄漏的先兆
    • JVM的heap区大小,通过java命令行中的-Xms,-Xmx指定,建议最小值和最大值设成一样,可以通过WebLogic console上server/monitor/performance来观察其使用情况,建议生产系统最256M,一般情况下可以设置为系统剩余物理内存的80%,Heap size太大在一些JVM上会有问题,对于sun和hp的JVM,permanent size太小也会出OutOfMemoryError,在java命令行上加-XX:MaxPermSize=128m
    • 尽量减少内存消耗,Session中不要放大的数据,并尽量在不再需要的时候remove掉,如果可以调整session timeout到较小的值,避免在J2EE server端应用里边调用AWT/swing作图,调整ejb的cache/pool设置
    • 内存泄漏,可以通过WebLogic console来观察JVM的heap memory使用情况来获知是否有内存泄漏情况,采用第三方辅助工具来获取更详细信息,如Jprobe/OptimizeIt;有可能是weblogic的bug,但绝大部分情况是由用户的应用引起的,最常见的代码问题是数据库连接没正常关闭。

     

    系统CPU

    • 如果用户访问量很大,CPU占用很高(user态)并不是异常
    • 如果是kernel态很多,需要OS厂商调整操作系统
    • 采用top找到占用CPU很多的进程,如果是非weblogic进程,应该考虑将其移到另外的server上运行,如果是运行weblogic的java进程,通过做thread dump(详细信息后边会介绍到)来确认是那段代码导致了这么高的CPU使用(也有可能是os/jvm本身不正常)

    系统文件描述符数目不足

    Log中有“too many open files”的错误,表示达到了系统对一个进程能同时打开的文件数的限制:

    • ulimit –a –H 可以查看当前限制
    • ulimit –n number可以来更改当前环境的设置,建议至少设到4096
    • Solaris上可以通过/usr/proc/bin/pfiles pid来查看指定进程的限制和当前使用的file descrīptor数目
    • Solaris上root用户可以通过/usr/proc/bin/plimit -n soft,hard pid 来动态更改进程的文件描述符的限制

    线程死锁

    对于原因不明的hang或是响应慢,最根本的方法就是获取thread dump信息,对于windows系统,在运行java的窗口按Ctrl+Break,对于UNIX系统,首先用ps找到运行weblogic的java进程的pid,然后执行kill –3 pid,JVM将负责将所有java进程的状态、执行堆栈dump到其标准输出,为了方便获取thread dump信息,在weblogic启动的时候,最好将其标准输出重定向到一个文件,为了反映线程状态的动态变化,需要接连多次做thread dump,每次间隔10-20s。

     

    对于thread dump信息,主要关注的是线程的状态和其执行堆栈,线程的状态一般为三类

    • Runnable(R):当前可以运行的线程
    • Waiting on monitor(CW):线程主动wait
    • Waiting for monitor entry(MW):线程等锁

    一般关注的都是第一和第三种状态的线程
    CPU很忙则关注runnable的线程
    CPU闲则关注waiting for monitor entry的线程
    一种典型的死锁是由于在server端应用(比如servlet)中请求由同一weblogic实例serve的资源,解决办法就是将该servlet放到另外的执行队列里去执行。

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=4525&tstart=0&quint=true

     

    "指定的网络名不再可用"错误

    wl6.1和wl7.0部署应用后都在后台抛出“java.net.SocketException: ReadFile failed: 指定的网络名不再可用”,这不是一个致命的错误,只会在中文Window上。如Hilaser和linstone提出了办法:

     

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=9393&tstart=0

     

     


    集群配置 集群简明配置过程

    在wls7中,集群的受管服务器无需使用相同的端口,这使在一个主机上实现集群成为可能。下面的例子是在一个主机(172.30.94.60)上的 wls7里创建一个集群(mycluster)DEMO,包括管理服务器(myserver:7001)、集群(两个受管服务器serverA: 8001、serverB:8003)、代理服务器(ProxyServer:80)。应用WebApp是部署在集群上的web应用,而 DefaultWebApp是部署在代理服务器上用来代理集群应用WebApp的。具体步骤如下:

     

    1.创建集群域clusterdomainnew,管理服务器myserver(7001:7003);

    2.创建Machine:admin(myserver,ProxyServer),cluster(serverA,serverB);

    3.创建受管服务器serverA(8001),serverB(8003);

    4.创建集群mycluster;

    Choose Servers for this Cluster: serverA,serverB

    config.xml:

    <Cluster ClusterAddress="172.30.94.60:8001,172.30.94.60:8003"

    MulticastAddress="237.0.0.1" MulticastPort="7777" Name="mycluster"/>

     

    5.部署WebApp应用,targets mucluster;

    6.创建代理服务器ProxyServer(80),将DefaultWebApptargets ProxyServer;

    7.编辑DefaultWebApp应用,注册HttpClusterServlet:

    <servlet>

    <servlet-name>HttpClusterServlet</servlet-name>

    <servlet-class>weblogic.servlet.proxy.HttpClusterServlet</servlet-class>

    <init-param>

    <param-name>WebLogicCluster</param-name>

    <param-value>172.30.94.60:8001:8002|172.30.94.60:8003:8004</param-value>

    </init-param>

    <init-param>

    <param-name>DebugConfigInfo</param-name>

    <param-value>ON</param-value>

    </init-param>

    </servlet>

    <servlet-mapping>

    <servlet-name>HttpClusterServlet</servlet-name>

    <url-pattern>/</url-pattern></servlet-mapping>

    <servlet-mapping>

    <servlet-name>HttpClusterServlet</servlet-name>

    <url-pattern>*.jsp</url-pattern> </servlet-mapping>

    <servlet-mapping>

    <servlet-name>HttpClusterServlet</servlet-name>

    <url-pattern>*.htm</url-pattern> </servlet-mapping>

    <servlet-mapping>

    <servlet-name>HttpClusterServlet</servlet-name>

    <url-pattern>*.html</url-pattern>

    </servlet-mapping>

    8.重启myserver;

    9.启动serverA:startManagedWeblogicserverAhttp://172.30.94.60:7001;

    启动成功后,访问http://172.30.94.60:8001/WebApp/ 验证一下!

    10.启动serverB:startManagedWeblogicserverBhttp://172.30.94.60:7001;

    启动成功后,访问http://172.30.94.60:8003/WebApp/ 验证一下!

    11. 启动ProxyServer:startManagedWeblogic ProxyServerhttp://172.30.94.60:7001。

    访问http://172.30.94.60/WebApp,是不是大功告成了:)

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=3257&tstart=25&quint=true

     

    WebLogic应用在集群环境下的一些基本知识

    基本概念

    1.硬件的cluster和WebLogic的cluster不是一回事,硬件做的是冷备份,对用户的session,用户请求的负载均衡等的处理是做不到的,而且一般硬件的双机热备也不是时时的备份,而是间隔一段时间再将主机上的数据copy过来,而WebLogic Server的cluster就不是这样,其session的数据是时时的复制的,对不经常更改的jndi等的复制虽然也是定期完成的,但update的时间间隔很短

    2.WebLogic Server的cluster配置非常方便,请参考dev2dev学堂

    http://dev2dev.bea.com.cn/techdoc/200506554.html

    如果你要对集群做扩展,操作也非常方便,你只需要启动一个指向这个集群的Admin Server的managed server就可以了,由这个集群中的唯一的Admin Server往这个managed server上部署应用
    3.http状态会话复制就是session的复制,例如你登陆了系统,如果一个服务器坏了,cluster会将你的请求转发集群中的另外一个server,由其继续处理你的这个请求,而不要重新登陆。
    4.EJB集群中有状态,无状态EJB的意义和区别请看J2EE中EJB的相关知识
    5.对EJB的集群,也是非常简单的,直接把EJB应用target到cluster的server上!
    6.对WebLogic Server来说,它的cluster做session的in memory的时时复制,这适用于web application及stateful session BEA的session内容的复制
    7.对非stateful的EJB,WebLogic Server的cluster做其负载均衡及failover的工作(failover只针对EJB的stateless BEAN

    集群规划

    在规划集群配置时,应该牢记以下关于网络环境与集群配置的限制。

     

    1.首先,集群中的WebLogic主机必须使用永久的静态IP地址。动态IP地址分配不能用于集群环境。如果服务器位于防火墙后面,而客户机位于防火墙外面,那么服务器必须有公共的静态IP地址,只有这样,客户端才能访问服务器。


    2.集群中的所有WebLogic服务器必须位于同一个局域网,并且必须是IP广播可到达的。


    3.集群中的所有WebLogic服务器必须使用相同的版本。配置集群中的服务器,使它们支持所提供的服务。对于使用了JDBC连接的EJB,所有部署了某EJB的服务器必须具有相同的部署与持久化配置。也就是说所有服务器都应该有相同的JDBC配置。所有部署了servlet的主机必须维护一组具有相同ACL的servlet。

    如果客户端应用直接使用JDBC连接池,那么你必须为每个WebLogic服务器创建相同的连接池(并具有相同的ACL)。这意味着集群所使用的连接池应该可以在所有的机器上创建。例如,一台运行WebLogic的NT服务器配置了连接Microsoft SQL Server数据库的连接池,那么一个包含非Windows机器(即不支持Microsoft SQL Server连接的机器)的集群不能使用这个连接池。

    其它配置细节可能会因不同的集群成员而不同。例如,一台Solaris服务器可以比一台小的 NT工作站处理更多的登录请求。这种差异是可以接受的。因此,正如这里所给出的例子,对于那些与性能相关的属性,你可以根据每个集群成员的特点来配置不同的值,只要所有成员的服务配置相同即可。因此,集群中的WebLogic服务器在所有与WebLogic服务、类文件以及外部资源(例如数据库)相关的方面具有相同的配置。

     

    服务器配置任务列表

    可以通过管理控制台进行以下服务器配置:

    • Server节点配置单独的服务器可以配置的属性包括名字:监听端口与IP地址。
    • Server节点克隆一个服务器:克隆的服务器保存了原来服务器的属性值,你可以使用Server节点中的Configuration配置新服务器的名字。
    • 使用管理控制台的Server节点来删除一个服务器:点击要删除的服务器的图标,将弹出一个删除服务器的确认对话框,点击对话框中的Yes按钮将删除服务器。
    • 使用管理控制台的Server节点查看一个服务器的日志:点击要查看的服务器,点击Monitoring标签页,点击View Server Log连结,便可以在管理控制台的右窗格查看服务器日志。
    • 使用管理控制台的Server节点查看一个服务器的JNDI树:点击所要查看的服务器,然后点击Monitoring标签页,点击该页面上View JNDI Tree连接,该服务器JNDI树的信息便显示在管理控制台的右窗格中。
    • 使用管理控制台的Server节点查看服务器的执行队列:点击所要查看的服务器,然后点击Execute Queue 链接,然后查看管理控制台右边窗格里的表格中的内容。
    • 使用管理控制台的Server节点查看服务器的执行线程:点击所要查看的服务器,然后点击Execute Queue 链接,然后查看管理控制台右边窗格里的表格中的内容:
    • 使用管理控制台的Server节点查看server sockets:点击所要查看的服务器,点击View Sockets连接,然后查看管理控制台右边窗格里的表格中的内容。
    • 使用管理控制台的Server节点查看服务器连接:点击所要查看的服务器,点击View Connections连接,然后查看管理控制台右边窗格里的表格中的内容。
    • 使用管理控制台的Server节点进行强制垃圾收集,点击要监控的服务器,点击JVM标签页,点击页面上的Force Garbage Collection连接,将弹出是否要进行垃圾收集的确认对话框。
    • Server节点监视服务器的安全:点击要监控的服务器,点击Monitoring标签页,点击Security标签页,将显示安全信息。
    • Server节点查看服务器的版本:点击要查看的服务器,点击Version标签页,将显示服务器的版本信息。
    • Server节点监控服务器集群:点击要监控的服务器,点击Cluster标签页,将显示该服务器的集群数据。
    • Server节点来部署EJB:点击需要部署EJB的服务器,点击需要分发的EJB并使用移动控件将它移到被选列中,点击Apply来保存你的选择。
    • Server节点来监视部署在某一服务器上的所有EJB:点击需要监视的服务器,点击Monitor All EJB Deployments连接来显示EJB的部署列表。
    • Server节点将web应用组件部署在某一服务器上:选择要部署web应用的服务器:选择需要部署的web应用,然后通过移动控件将它移到被选列中,点击Apply来保存你的选择。
    • Server节点来监控某一服务器上的所有web应用组件:点击web应用所在的服务器,然后点击Monitor All Web Applications连接来显示Web Application 的部署列表。
    • Server节点在服务器上部署启动与终止类:点击需要部署启动类的服务器,然后点击需要部署的启动类并将它移到被选列中,点击Apply来保存你的选择,使用终止类控件来部署终止类的过程与此相同。
    • Server节点为服务器分配JDBC连接池:点击web server分配表中的一个服务器,在Available列中点击一到多个JDBC连接池,并通过移动控件将所选择的JDBC连接池移到Chosen列,点击Apply来保存你所做的分配。
    • Server节点为一个服务器分配WLEC连接池:点击需要分配WLEC连接池的服务器:在Available列中选择一个或多个要分配的WLEC连接池,使用移动控件将所选择的WLEC连接池移动到Chosen列。
    • 通过管理控制台的Server节点监视某一服务器上的所有WLEC连接池:选择一个需要监视连接池的服务器,点Monitor All WLEC Connection Pools on This Server链接,所有分配给这台服务器的连接池会显示在右窗格中的WLEC Connection Pools列表中。
    • Server节点为一台服务器分配XML 注册表,选择要分配XML 注册表的服务器,从XML 注册表的下拉列表中选择一个注册表,点Apply保存设置。
    • Server节点分配邮件会话:选择一个要分配邮件会话的服务器,从Available列中选择要分配给服务器的邮件会话,使用移动控件把所选择的移动会话移动到Chosen列中,点Apply按钮保存设置。
    • 通过管理控制台为服务器分配文件T3s:选择一个要分配文件T3的服务器,从Available列中选择要分配给服务器的文件T3s,使用移动控件把所选择的文件T3s移动到Chosen列,点Apply按钮保存设置。
    • Connection连接,然后查看管理控制台右边窗格里的表格中的内容。
    • 使用管理控制台的Server节点进行强制垃圾收集:点击要监控的服务器,点击JVM标签页,点击页面上的Force Garbage Collection连接,将弹出是否要进行垃圾收集的确认对话框。

     

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=4800&tstart=0&quint=true

     


    安全管理 WebLogic AD ldap 配置方法

    Weblogic AD ldap 配置方法

     

    一创建并配置windows端AD.

    1 在AD中加入新的OU,myOrg.

    2 在myOrg中加入两个ou ,groups 和people。在groups中加入两个组group1,group2,在people中加入两个用户user1,user2.

    3配置user1用户属于组group1,user2用户属于组group2。

    windows Active Directory 端配置完毕。

     

    二得到配置参数

    1 下载ldap brSofterra LDAP Browser 2.5 (可用google搜索)

    2 配置ldap browser。

    打开ldap browser应用程序。创建新的profile。

     

    填入参数:

    单击fetch DNs (only ldap v.3) 得到自动配置的ldap 基础配置

    在DC=www 前面加入AD中配置的OU=myOrg。

    完成后如下图。表示连接AD 成功

    得到base DN 参数为 ōU=myOrg,DC=www,DC=test,DC=com, (DC=www,DC=test,DC=com视您的windows域而定,本例域为www.test.com)。

     

    三配置weblogic server

    启动域,打开控制器http://localhost:7001/console。

    配置新的authentication。

    点击authentication 。在右边选择configure a new active directory authenticator

     

    1 General 中的配置

    2 Active Directory栏配置

    3 user栏配置

    user栏只需要修改User Base DN 为自己的user base DN,这里填入ldap browser 中得到的数据OU=myOrg,DC=www,DC=test,DC=com,不过我们要得到的是用户所以在前面在加入我们创建的OU=people。

    4 group 栏配置。

    group 栏只需要修改group Base DN 为自己的group base DN,这里填入ldap browser 中得到的数据OU=myOrg,DC=www,DC=test,DC=com,不过我们要得到的是组所以在前面在加入我们创建的OU=groups。

     

    保存后其余的都不用在修改了。

    我们再次点击user时,ldap中的用户和组就加入到weblogic server 的用户中了

     

    原文地址:

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=8194&tstart=25&quint=true

     

    口令的保护

    保护用来访问WebLogic服务器资源的口令是很重要的。在过去,用户名与口令以明文的形式存储在WebLogic服务器的安全域中。现在 WebLogic服务器对所有口令进行散列化。当WebLogic服务器获得一个客户端请求时,客户端所输入的口令也被散列化,然后把散列化结果与所保存的散列化口令进行比较,看它们是否相互匹配。

     

    每个filerealm.properties文件都有一个与它关联的SerializedSystemIni.dat文件,这个文件被用来散列化口令。在安装时,SerializedSystemIni.dat文件保存在\wlserver6.1\config\mydomain目录下,如果该文件被破坏,那么就需要重新配置WebLogic服务器。

    我们建议你采用以下预防措施:

    备份SerializedSystemIni.dat文件,并将其与filerealm.properties文件的备份存放于同一目录下。设置SerializedSystemIni.dat文件的访问权限,例如只允许WebLogic服务器的管理员有读写这个文件的权限,其它用户没有这个文件的任何权限。

     

    如果你使用的是weblogic.properties文件,并且想散列化这个文件中的口令,你可以用管理控制台主窗口的Convert weblogic.properties选项将weblogic.properties文件转换为config.xml文件。一旦文件被转换,则所有现存的口令就已经被保护了。

     

    Config.xml文件中的不在含有明文的口令,若在其中保存明文的口令,config.xml会对其进行加密并被散列化该口令。被加密的口令不能从一个域复制到另一个域,而是应该使用明文口令替换config.xml中被加密的散列化口令,然后再将文件复制到另外一个域中。管理控制台在下一次写文件时会加密并散列化口令。

     

     

     

    要保护WebLogic服务器的口令,执行以下操作:

    1. 打开管理控制台

    2. 点击Security节点

    3. 在管理控制台右侧窗格中选择Passwords标签页。

    4. 定义该标签页中需要配置的属性,按照相应的提示输入值,并选中必须选择的复选框(详细信息,参见下表)。

    5. 点Apply按钮保存所做的设置

    6. 重启WebLogic服务器。

     

    如下详细描述了Security Configuration窗口的Password标签页上的各个属性。

    • Minimum Password Length: 口令所需的长度,至少为8个字符。缺省为8个字符
    • Lockout Enabled: 在超过Lockout Threshold次尝试后,是否需要锁住某个登录无效的帐号。缺省情况下,该属性被启用。
    • Lockout Threshold:当一个用户试图登录到一个用户帐户,因口令不对而失败,那么多少次这样的失败登录后将锁住这个帐号。以后对该帐号的访问(即使是username/password是正确)也将引发Security异常;在管理员对该帐号进行解锁前,或在锁住期限内,该帐号一直处于锁住的状态。注意非法登录必须在Lockout Reset Duration属性所定义范围内。默认为5
    • Lockout Duration:该属性定义了当某一帐户因为在Lockout Reset Duration期限内发生非法登录而被锁住后,多长时间范围内该用户帐号不能被使用。要解开一个被锁住的用户帐号,你必须拥有 weblogic.passwordpolicy中的unlockuser权限。默认为30分钟。
    • Lockout Reset Duration:该属性定义了在多长时间里,非法登录某一帐号将导致该帐号被锁住。在本属性定义的时间范围内,当非法登录的次数超过了Lockout Threshold属性所定义的值,那么该帐号将被锁住,例如,该属性被设置为5分钟,当帐号在6分钟内被非法登录了3次,那么该帐号不会被锁住,但是,如果在5分钟内,发生了5次非法登录,那么该帐号将被锁住。缺省为5分钟。
    • Lockout Cache Size:指定无效的或非法的登录意图的缓存大小。缺省为5

     

    注:本文针对weblogic6,其他版本请参考

     

    原文地址

    http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=930&tstart=50&quint=true

     


    其它资源

    本文前面部分删除了许多重复的文章,也没有包括一些比较复杂的文章,大家可以到Dev2dev WebLogic管理板块

    http://dev2dev.bea.com.cn/bbs/forum.jspa?forumID=81&start=0

    和本版精华

    http://dev2dev.bea.com.cn/bbs/forum!quint.jspa?forumID=81

    下查看。

    本文随同本论坛其它板块的资料,也保留在社会书签http://del.icio.us/dev2dev.cn处,大家可以也尝试使用这种书签,来共同维护我们的资源,人多力量大。以下我说说其他有用资料。

    dev2dev 学堂

    这里的资料十分的丰富。

    • 实战集锦非常实用,里面主要包括了一些WebLogic出现的问题以及解决方案,其中你不仅可以学到WebLogic的许多知识,也可以知道许多Java与操作系统的基础知识,也可以发现许多排错和调优的好工具以及使用方法。
    • WebLogic Server里面包括了大量的基础教程,既有图文并茂的教程,也有许多动画教程。你可以学到WebLogic的在Windows和Linux/UNIX下的安装,可以学到如何配置SSL和集群,如何发布简单应用程序,如何使用JMS,如何调用你的第一个JSP文件。
    • WebLogic常见问题包括经常遇到了简单问题以及快捷的回答。

     

    dev2dev 学堂:http://dev2dev.bea.com.cn/bbs/school/index.html

    实战指南:http://www.bea.com.cn/support_pattern/index.htm

    WebLogic Server学堂:http://dev2dev.bea.com.cn/products/wlser/list1.html

    常见问题:http://www.bea.com.cn/services/custsupp/techresor/faq/faq_weblogic_list.jsp

    WebLogic代码库和CodeShare

    代码库是以前WebLogic为大家提供的一些代码实例,CodeShare是最近发起的一个项目,代码库的许多代码会转移到CodeShare下,但是现在还没有完全做到,许多代码还只能在代码库里找到。如果想学习某些比较复杂的技术,看实例代码是最好的方式,而且这些代码通常会附有非常详细的文档来帮助使用。

     

    代码库:http://dev2dev.bea.com.cn/resource/codelib/index.html

    代码库Weblogic部分:http://dev2dev.bea.com/code/wls.jsp

    CodeShare:http://dev2dev.bea.com.cn/resource/codeshare/index.html

     

    在线论坛Dev2dev

    有一些文章没有收录到这里,主要是因为篇幅太长,或者内容与网站的其他地方有些重复,可是还是很精彩的文章。

     

    学习WebLogic起步过程

    经常有人问WebLogic如何起步,这里列下大体的过程,具体可以参考dev2dev学堂和论坛精华。

    • 下载
      http://dev2dev.bea.com.cn/doccenter/soft.html下载相应的版本
    • 安装
      只以windows为例,直接运行下载的安装程序就然后根据步骤一路默认就好。
    • 配置最基本的domain
      WebLogic安装好后应该在运行“开始-所有程序-Bea WebLogic Platform-Configuration Wizard”或者是"C:\bea\weblogic81\common\bin\config.cmd",就可以配置一个Domain,也就是一组服务器单元。
    • 使用console
      配置好了一个domain,就可以启动Admin Server,可以使用“开始 - 所有程序 - Bea WebLogic Platform - Configuration Wizard - User Projects – mydomain – Start Server”, 或者是到了mydomain目录调用startWebLogic.cmd,就可以启动Server,然后在浏览器中进入http://localhot:7001/conole就进入了管理界面,通常的管理都在这里进行。
    • 发布应用
      可以到console的Deployment部分发布

     

  • Weblogic服务器性能调优(转载自中国源码网)

    2006-12-30 15:47:48

    http://www.yuanma.org/data/2006/0808/article_1329.htm

    注:在下面做的介绍都是以Weblogic8.1为例的,其它版本的Weblogic可能会有些许不同。

           1) 设置JAVA参数;

           a) 编辑Weblogic Server启动脚本文件;

    l         BEA_HOME\user_projects\domains\domain-name\startWebLogic.cmd(startWebLogic.sh on Unix)

    l         BEA_HOME\user_projects\domains\domain-name\startManagedWebLogic.cmd(startManagedWebLogic.sh on Unix)

    b) 编辑set JAVA_OPTIONS命令,如:set JAVA_OPTIONS=-Xms256m –Xmx256m

    c) 保存,重启即可。

    注:在WebLogic中,为了获得更好的性能,BEA公司推荐最小Java堆等于最大Java堆。

    2) 开发模式 vs. 产品模式;

    开发模式和产品模式的一些参数的默认值不同,可能会对性能造成影响,下面是对性能有影响的参数列表:

    参数

    开发模式默认值

    产品模式默认值

    Execute Queue: Thread Count

    15 threads

    25 threads

    JDBC Connection Pool: MaxCapacity

    15 connnections

    25 connections

           通过启动管理控制台,在域(如:mydomain> 配置 > 常规选择产品模式。

    3) 尽量开启本地I/O

    通过启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver> 配置 > 调整选择启用本地I/O

    注:此值也可通过手动的修改config.xml配置文件。

    4) 调优执行队列线程;

    a) 修改默认执行线程数

    在这里,执行队列的线程数表示执行队列能够同时执行的操作的数量。但此值不是设的越大越好,应该恰到好处的去设置它,太小了,执行队列中将会积累很多待处理的任务,太大了,则会消耗大量的系统资源从而影响整体的性能。在产品模式下默认为25个执行线程。

    为了设置理想的执行队列的线程数,我们可以启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver> 监视 > 性能中监控最大负载时执行队列的吞吐量和队列中的等待请求数,据此确定理想的数值。

           理想的默认执行线程数是由多方面的因素决定的,比如机器CPU性能、总体体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。随着CPU个数的增加,WebLogic可以近乎线性地提高线程数。线程数越多,花费在线程切换的时间也就越多;线程数越小,CPU可能无法得到充分的利用。为获取一个理想的线程数,需要经过反复的测试。在测试中,可以以25*CPU个数为基准进行调整。当空闲线程较少,CPU利用率较低时,可以适当增加线程数的大小(每五个递增)。对于PC ServerWindows 2000,则最好每个CPU小于50个线程,以CPU利用率为90%左右为最佳。

           通过启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver> Execute Queue > weblogic.kernel.Defalt > 配置中修改线程计数。

           b) 设定执行队列的溢出条件;

           Weblogic Server提供给默认的执行队列或用户自定义的执行队列自定义溢出条件的功能,当满足此溢出条件时,服务器改变其状态为“警告”状态,并且额外的再分配一些线程去处理在队列中的请求,而达到降低队列长度的目的。

           通过启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver> Execute Queue > weblogic.kernel.Defalt > 配置下面几项:

    l         队列长度:此值表示执行队列中可容纳的最大请求数,默认值是65536,最后不要手动改变此值。

    l         队列长度阈值百分比:此值表示溢出条件,在此服务器指出队列溢出之前可以达到的队列长度大小的百分比。

    l         线程数增加:当检测到溢出条件时,将增加到执行队列中的线程数量。如果CPU和内存不是足够的高,尽量不要改变默认值“0”。因为Weblogic一旦增加后不会自动缩减,虽然最终可能确实起到了降低请求的作用,但在将来的运行中将影响程序的性能。

    l         最大线程数:为了防止创建过多的线程数量,可以通过设定最大的线程数进行控制。

    在实际的应用场景中,应根据具体情况适当的调整以上参数。

    c) 设定执行队列监测行为

    Weblogic Server能够自动监测到当一个执行线程变为“阻塞”。变为“阻塞”状态的执行线程将无法完成当前的工作,也无法再执行新请求。如果执行队列中的所有执行线程都变为“阻塞”状态,Weblogic server可能改变状态为“警告”或“严重”状态。如果Weblogic server变为“严重”状态,可以通过Node Manager来自动关闭此服务器并重新启动它。具体请参考:Node Manager Capabilities文档。

    通过启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver>配置 > 调整下可配置下面几项:

    l         阻塞线程最长时间:在此服务器将线程诊断为阻塞线程之前,线程必须连续工作的时间长度()。默认情况下,WebLogic Server 认为线程在连续工作 600 秒后成为阻塞线程。

    l         阻塞线程计时器间隔:WebLogic Server 定期扫描线程以查看它们是否已经连续工作了 "阻塞线程最长时间" 字段中指定的时间长度的间隔时间()。默认情况下,WebLogic Server 将此时间间隔设置为 600 秒。

    5) 调优TCP连接缓存数;

    WebLogic ServerAccept Backlog参数规定服务器向操作系统请求的队列大小,默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。Login TimeoutSSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。

    通过启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver>配置 > 调整下可配置“接受预备连接”。

    6) 改变Java编译器;

    标准的Java编译器是javac,但编译JSP servlets速度太慢,为了提高编译速度,可以使用sjjikes编译器取代javac编译器。下面说说更改Java编译器:

    通过启动管理控制台,在域(如:mydomain> 服务器 > server实例(如:myserver>配置 > 常规下改变Java 编译器,默认为javac。输入完整路径,如:c:\visualcafe31\bin\sj.exe。然后打开高级选项,在预规划到类路径填写编译 Java 代码时为 Java 编译器类路径预规划的选项,如:BEA_HOME\jdk141_02\jre\lib\rt.jar

    7) 使用Webogic Server集群提高性能;

    具体关于如何配置Weblogic集群,我就不细说了。详情可参考:Introduction to WebLogic Server Clustering

    8) Weblogic EJB调优

    由于EJB2.0已经很少项目在用了,EJB3.0再成熟一点,我再补充这一部分吧!

    9) JDBC应用调优

    JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗,建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致。

    增加Statement Cache Size对于大量使用PreparedStatement对象的应用程序很有帮助,WebLogic能够为每一个连接缓存这些对象,此值默认为10。在保证数据库游标大小足够的前提下,可以根据需要提高Statement Cache Size。比如当你设置连接数为25,Cache Size10,数据库可能需要打开25*10=250个游标。不幸的是,当遇到与PreparedStatement Cache有关的应用程序错误时,你需要将Cache Size设置为0

    尽管JDBC Connection Pool提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved ConnectionsTest Released Connections也无需勾上。 当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开。

    最后提一下驱动程序类型的选择,Oracle为例,Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。所以在通常情况下建议使用thin驱动。而最新驱动器由于WebLogic server/bin目录下的类包可能不是最新的,请以Oracle网站为准: http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html

    10) JSP调优

    l         设置jsp-param pageCheckSeconds=-1

    l         设置serlet-reload-check=-1ServletReloadCheckSecs=-1

    l         设置jsp-param precompile=true,关闭JSP预编译选项。 

     

     

    其它资源: http://www.chinaitpower.com/2005September/2005-09-13/206361.html

我的栏目

数据统计

  • 访问量: 6480
  • 日志数: 9
  • 建立时间: 2006-12-30
  • 更新时间: 2007-06-27

RSS订阅

Open Toolbar