3.3 作用域的划分

　　我们在人工分析一个应用程序的代码时，通常先会查看应用程序的总体情况，然后分析应用程序中的各个类(对于使用面向对象这类语言实现的代码来说)，进而再分析类中的成员函数。

　　Audit在分析、显示对代码的审查结果时，也按这种形式进行划分，我们称它为作用域，比如对于C++、Java语言实现的代码，Audit划分的作用域有：应用程序作用域、类作用域、函数作用域。通过它们的名字，你应该可以猜出各个作用域所包含的内容。应用程序作用域针对整个应用程序，类作用域针对系统中的各个类，函数作用域针对系统中的各个函数。

　　不同作用域之间是彼此独立的，但它们都是遵照我们前面提到的那个质量模型对代码进行分析。

　　3.4 Audit对代码的处理过程

　　对于使用Audit的用户来说，输入的是源程序代码，输出的是Audit的分析结果。Audit对代码的处理过程如图所示：

　　3.5 结束

　　好了，Audit的测试机理到此就介绍完了。

　　4 Rulechecker检测机理。

　　现在来介绍一下Logiscope为我们提供的另外一个工具——Rulechecker。Rulechecker也是一个静态测试工具。

　　先回想一下我们组织内部的编码规范。编码规范中会对程序代码的注释、变量命名、书写格式等各个方面做出规定，其目的，是为了让开发人员书写的代码更健壮，可读性更好。Rulechecker这个工具也是为了协助我们实现使代码更健壮，可读性更好这个目的的。

　　Rulechecker实现了一个编码规范集。在这个规范集中的内容，与我们组织内部定义的编码规范的内容类似，但覆盖的范围要更广，规定的也更细(关于Rulechecker编码规范集中各条编码规范的详细内容，可以阅读我写的另一篇文章《RuleChecker编码规范》，在这里就不做描述了)。

　　在这个规范集中，有将近一半左右的编码规范，我们可以对其内容进行定制，这就大大增加了灵活性，使Rulechecker能更好的适应我们实际情况的需要。

　　在具体的测试过程中，Rulechecker的编码规范是如何发挥作用的呢?在我们为被测代码建立Rulechecker项目的过程中，有一步是让我们“Choose a configuration file”，这就是让我们选择一个编码规范描述文件，Rulechecker为我们提供了一个叫做‘RuleChecker.cfg’的编码规范描述文件，我们当然可以修改或重新编写一个.cfg文件，来适应我们的要求。

　　下面举Rulechecker编码规范集中一个编码规范的例子：Headercom编码规范

　　Headercom编码规范对代码文件的文件注释做出了规定，具体内容为：“每个代码文件的头部必须有文件注释，且注释要遵照一定的格式”。这个格式可由我们来设定。

　　我现在将Headercom规范要求的注释格式，设置成与我所在公司的编码规范中规定的文件注释相同的格式。 打开RuleChecker.cfg文件，用下面的内容代替文件Headercom原来的内容。

　　STANDARD Headercom ON

　　LIST "HEADER" "【文件名】"

　　"【功能模块和目的】"

　　"【主要函数及其功能】"

　　"【主要算法】"

　　"【接口说明】"

　　"【开发者及日期】"

　　"【版本】"

　　"【更改记录】" END LIST

]]> Tue, 08 Jun 2010 11:11:50 GMT http://www.ltesting.net/images/defaultpic.gif WebLogic 秩名 领测软件测试网_专业软件测试工程师探讨软件测试技术第一门户 http://www.ltesting.net/ceshi/ruanjianceshikaifajishu/rjcskfyy/zjj/weblogi/2010/0608/171884.html 　　Logiscope测试机理[1]   软件测试

　　1前言

　　本文介绍了静态测试工具Logiscope的测试机理。通过对Logiscope测试机理的了解，能帮助我们更好的使用这个工具。

　　通过阅读本文，你可以了解到以下信息：

　　◆Logiscope是如何分析软件产品质量的;

　　◆Logiscope是如何检测代码的编码规范的;

　　◆Logiscope是如何统计测试覆盖率的;

　　2 Logiscope总览

　　Logiscope有三项主要功能，以三个独立工具的形式出现，分别是：

　　软件质量分析工具——Audit;

　　代码规范性检测工具——Rulechecker;

　　测试覆盖率统计工具——TestChecker。

　　Audit和Rulechecker提供了对软件进行静态分析的功能，TestChecker提供了测试覆盖率统计的功能。

　　Logiscope可以对多种语言实现的代码进行分析，比如C、C++、Java、Ada，等等。下面的内容与具体的语言基本是没有关系的，但如果某些地方确实要涉及具体的语言，则我都是以C++为例。

　　下面，我对Audit、Rulechecker和TestChecker的测试机理，分别进行介绍。

　　3 Audit测试机理;

　　3.1软件质量模型

　　前面已经说过，Audit是审查程序代码质量的。要讨论代码的质量，就需要先说明一下软件质量模型的概念，因为理解下面的内容需要软件质量模型的相关知识。

　　如果你原来学习过软件质量保证的相关知识，那么应该会对软件质量模型这个概念有印象。为了说明Audit的测试机理，在这里只对软件质量模型做个简单的介绍。如果你对软件质量模型的概念比较陌生，建议找一本讲述软件工程方面的书，阅读一下软件质量保证部分的内容。

　　软件质量模型是一个分层结构，它的一般形式如下图所示：

　　质量因素处于质量模型中最高一级。软件的质量因素包括功能性、可靠性、易用性、效率、可维护性、可移植性这六个方面(在ISO/IEC 9126中有详细的描述)。

　　在质量因素之下，又细分成多个质量标准。

　　每个质量标准又由多个质量度量元组成。这些质量度量元处于质量模型分层结构中的最底层。

　　质量因素、质量标准一般是固定的，就是这几类，但质量度量元不是固定的，可以根据不同的情况发生变化。

　　软件质量模型就是一个将程序信息由底层到高层、由细节到概括的一个过程模型，它由简单、可测量的数据入手，最后分析概括出软件的特征。

　　3.2 Audit对软件质量模型的实现

　　上面我们了解了软件质量模型的大体结构，Audit也是按照这种分层、量化的方式来审查代码质量的。

]]> Tue, 08 Jun 2010 11:07:54 GMT http://www.ltesting.net/images/defaultpic.gif WebLogic 秩名 领测软件测试网_专业软件测试工程师探讨软件测试技术第一门户 http://www.ltesting.net/ceshi/ruanjianceshikaifajishu/rjcskfyy/zjj/weblogi/2010/0311/169757.html 　　WebLogic Server中CMP实体bean的性能调优[10]  软件测试

　　Read-mostly数据

　　也许最常见的情形是，数据被读取的频率大于其被更改的频率。这正是缓存可成功应用的场合。我建议使用启用了事务间缓存的乐观锁定。如果数据库模式可更改，我通常指定一个verify-columns的整型值，如果数据库模式不可更改，就指定一个Modified值。如果您决定使用一个版本列，那么要保证外部进程(如果有的话)在数据发生变更时遵守版本列更新的协定;否则，面临更新丢失的风险。

　　从选择适当的缓存大小方面来看，应该考虑多版本化，以及从finder方法返回的最大bean数目。一个不错的上限估计方法是将应用程序需要同时处理的最大事务数乘以单个事务可以处理的最大bean数。我通常建议使用更加灵活的应用程序级缓存，因为通常不太可能所有的CMP都同时被使用。应用程序缓存对于所有CMP来说是全局的，会自适应不同bean的活动。如果您定义了一个过大的应用程序级缓存，可能会损害性能，因为所有事务都会串行访问这个唯一的缓存。对于大小适当的缓存来说极少出现这个问题，但是同样，在您不确定缓存大小如何影响性能时应该进行性能测试。顺便说一下，良好的设计实践是，避免创建返回任意多实体bean的finder方法(比如，大型表上的findAll())，因为这使得估计出适当的缓存大小变得几乎不可能。

　　带有事务间缓存的乐观并发最适合有缓存碰撞“保护”的用例。比如，在一个项目用例中，应用程序需要处理传入消息(来自JMS)。每个消息记录需要在数据库表中创建，然后必须发送另一个消息作为响应;对于第二个消息来说，应用程序希望在一分钟内收到响应，并且在收到该响应时，同一条数据库记录得到更新。这时在该场景中应用缓存会带来巨大和直接的性能收益。我们“保证”每个被缓存的项目至少有一个碰撞，如果缓存对于保存CMP实例来说过大的话。

　　另一个极端是目标表太大，以至于不可能对同一数据作出重复请求。从实践角度来看，这是不可行的，并且缓存这样的数据不能提高性能。

　　在上述的read-mostly模式中，乐观并发模式应该是更好的选择。read-mostly模式不能用于集群中，不能防止出现更新丢失，并且一般来说不便于使用。本文讲述它是为了提供关于所有可用策略的整体情况，但是我不鼓励在现代应用程序中使用它。

　　Read-mostly数据

　　如果您的应用程序主要是插入或更新记录，那么缓存数据意义不大，因为几乎不会再次访问它们。在只进行插入操作(OLTP)的极端情况下，缓存反而会减慢处理速度。非重复性更新(对表中远超过缓存大小的随机行的更新)也很少从CMP缓存中受益。此外，随着更新数目相对于读取次数的增加，乐观并发策略的表现越来越差，因为会出现大量的乐观并发异常。实际上，如果您的应用程序只在数据库中更新和插入记录，就根本没有必要使用实体bean。

　　结束语

　　从本文的长度就可以看出，调整CMP 2.0 EJB有很多内容。我首先讲述了可用的各种并发策略。然后讨论了一些重要的性能策略：read-mostly模式，事务间缓存，以及选择最佳缓存大小。最后，我提供了关于在何种情况下使用何种策略的指南。我希望这些分析能帮助你更好地理解EJB。

　　应用程序级缓存

　　如果您的应用程序使用了很多实体bean，那么分析和配置各个bean的缓存会很麻烦。估计从“master-detail”关系的“detail”端返回的bean实例数尤为困难——比如，如果您的应用程序在“订单”表上执行一个finder操作，每个订单都有一个“项目”数可变的集合。另一个问题是由于每个实体bean都有一个单独的缓存，内存没有得到最有效的利用。认识到“每个bean一个缓存”模型的限制，WebLogic Server(从版本7开始)开始支持实体bean的应用程序级缓存。这使得同一个J2EE应用程序中的多个实体bean共享一个运行时缓存。

　　应用程序级缓存提供了下列好处：它减少了实体bean缓存的数目，从而减少了配置缓存的工作量。 它充分利用了内存和堆空间，因为减少了分段。比如，如果某一特定EJB经历了一次突发活动，它可以使用联合缓存中可用的所有内存，而使用该缓存的其他EJB都被换出。如果两个EJB使用不同的缓存，当一个bean的缓存满时，容器就不能将EJB换出到另一个bean的缓存中，导致了内存浪费。 它简化了管理;联合缓存使系统管理员只需调整单个缓存，而不是很多个缓存。 它提供了更好的可伸缩性。

　　为了定义应用程序级缓存，首先配置weblogic-application.xml中的entity-cache元素。然后在weblogic-ejb-jar.xml中引用entity-descriptor元素中entity-cache-ref元素中的应用程序级缓存。您可以定义一个缓存，然会将其用于应用程序中的所有实体bean，或者为bean组定义不同的缓存。也可以将应用程序级缓存与每个bean一个缓存混合使用，这样您就有很大的试验空间。我建议首先从被所有实体bean共享的应用程序级缓存开始，除非您有某些特殊需求。

　　使用应用程序级缓存是为每个bean指定一个缓存的可行的替代方法。可引用单个缓存的不同实体bean的数目或者已定义缓存的数目没有限制。可根据bean实例数(与每个bean一个缓存类似的方法)或者最大内存空间来指定缓存大小。从管理角度来看，使用内存的大小很有吸引力，但是要知道WebLogic Server不计算缓存中bean消耗的实际内存数(这可能是一项代价很高的操作);它只是根据weblogic-ejb-jar.xml部署描述符中规定的bean平均大小来分割内存。如果没有指定大小，则假定每个bean平均有100字节。我认为根据bean实例数指定缓存大小会更透明。

　　选择哪项策略?

　　本文已经讨论了很多内容，但是还未提及可应用于CMP bean的优化技术。比如，CMR缓存和字段组在某些环境下也很有用。选择最佳并发策略并充分利用长期缓存会给您的应用程序带来直接的性能提升。由于现在各个WebLogic Server版本中可用的选项有诸多不同(对于其他J2EE服务器也是如此)，所以有时候很难在某一具体情况下做出选择，尤其是如果开发人员没有调整这些参数的经验的话。如果根本没有指定并发策略和缓存参数，WebLogic Server使用的默认设置从数据一致性方面考虑当然是不错的选择，但是从CMP bean的性能方面来看却不是最佳选择。没有放之四海皆准的东西，所以如果您不确定的话，应该分析您的用例，然后利用不同的并发设置进行测试，然后再作出最佳选择。接着，我会讨论一些基本用例以及它们的推荐设置。

　　静态只读数据

　　最可能的场景是，当数据库是静态(不随时间变化)、准静态(变化不频繁)，或者从应用程序的角度来看可当作静态或准静态，并且您的应用程序不修改这些数据时。比如，数据可能被外部进程频繁更新，但是如果您的应用程序只是每分钟/小时/天看到这些更新，那么就没问题。这种情况下，使用带有适当read-timeout-seconds值的只读并发策略是合乎逻辑的。如果您的应用程序需要按照某种预定时间间隔看到更新，或者有一个批处理过程来加载数据，而你需要马上看到新数据，那么就可以像前面描述的那样，显式地禁用缓存。比如，您可以在应用程序的正面暴露一个“CMP缓存失效服务”，然后在批处理的最后或者从调度程序中调用。这种情况下缓存大小很容易计算，因为需要该缓存的所有事务共享同一个CMP实例，所以不需要考虑多版本及其对缓存大小的影响。要根据表大小、单个对象大小以及可用内存选择合理的缓存大小。

    　WebLogic Server 9.0中的改进

　　在WebLogic Server 9.0中，对使用乐观并发的缓存bean进行的显式缓存禁用被归档，并且与只读bean一致。(比如，bean home或远程主接口可被缓存到上面调用的CachingHome或CachingLocalHome和invalidate()方法中)。此外，read-timeout-seconds参数适用于用乐观并发部署的bean。开发人员还对集群中的bean实例无效化有更多的控制。默认情况下，当在一个集群中部署具有乐观并发策略的bean，并且该集群的一个成员更新该bean时，WebLogic Server会试图使该集群的所有节点中的bean的所有副本无效。该无效化使您避免了乐观并发故障，但是会影响性能，因为它是一项资源密集型操作。可通过在weblogic-cmp-jar.xml中将cluster-invalidation-disabled设置为true来防止EJB容器使集群中的bean副本无效。

　　为实体Bean选择最佳缓存大小

　　既然您理解了事务间的缓存是如何工作的，下面就让我们讨论一下选择最佳缓存大小方面的重要话题。默认情况下，每个实体bean都定义有一个大小为1000的缓存。缓存大小由weblogic-ejb-jar.xml部署描述符中的max-beans-in-cache元素控制。我发现该名称有些令人误解，因为根据并发策略的不同，WebLogic Server保存无状态的实体bean实例池(采用数据库并发策略和排他性并发策略，且事务间缓存被禁止的情况下)或者(只读、乐观或排他性并发策略，且事务间缓存启用的情况下)保存具有保留字段值的bean的真正缓存，从而无需从数据库中重新加载bean的状态就可使用。后一种情况更有趣。有人可能会想，更改缓存大小只影响具有实体bean的操作的性能;缓存越大，在缓存中发现需要的特定实体bean实例的机会就越大。基本上是这样的，但是如我下面会讲到的那样，另一个重要因素会影响缓存大小的选择。

　　多版本化和事务的因素

　　确定实体bean缓存大小的推动因素之一(可能不太明显)是当事务使用实体bean时，它们在事务的执行期间被实际加载和“固定”在实体缓存中，即使调用者不在修改实体bean实例而仅是从中读取值。比如，想象一下，一个会话或MDB bean中的代码在一个实体bean “Person”上执行一个finder方法，然后在返回的集合上迭代。

　　...

　　Collection persons = personLocalHome.findSomething();

　　for (Iterator iter = persons.iterator(); iter.hasNext();) {

　　PersonLocal person = (PersonLocal)iter.next();

　　Long id = person.getId();

　　// do something: log, send email, etc

　　...

　　}

　　...

　　如果findSomething()方法返回比max-beans-in-cache中规定的值更多的对象，您的应用程序将在迭代器得到N+1个对象时(N为当前实体缓存大小)获得一个令人不愉快的(并且很可能是不想要的)CacheFullException。这可能看上去很重要，因为一般大家都认为finder不应返回很大的集合。但是不要忘记默认情况下WebLogic实体缓存是多版本的，这意味着如果多个事务请求同一个实体bean实例，那么会在缓存中创建多个版本(每个事务一个);从唯一对象的角度来看这可能极大地降低了缓存容量。

]]> Thu, 11 Mar 2010 10:09:26 GMT http://www.ltesting.net/images/defaultpic.gif WebLogic 秩名 领测软件测试网_专业软件测试工程师探讨软件测试技术第一门户 http://www.ltesting.net/ceshi/ruanjianceshikaifajishu/rjcskfyy/zjj/weblogi/2010/0311/169754.html 　　WebLogic Server中CMP实体bean的性能调优[7]  性能测试工具　

  　下面基于Cactus的测试验证了该行为。假定一个Person CMP bean是利用乐观并发部署的，并且cache-between-transaction被设置为true：

　　...

　　public class OptimisticLockingTest extends ServletTestCase {

　　private UserTransaction tx;

　　protected void setUp() throws Exception {

　　super.setUp();

　　Context context = new InitialContext();

　　this.tx = (UserTransaction)context

　　.lookup("javax/transaction/UserTransaction");

　　}

　　public void testCacheBetweenTransactions() throws Exception {

　　PersonLocalHome localHome = (PersonLocalHome)Locator

　　.getLocalHome(PersonLocalHome.JNDI_NAME);

　　// create record via CMP in first transaction

　　this.tx.begin();

　　PersonLocal local = localHome.create();

　　local.setName("John");

　　Long pk = local.getPrimaryKey();

　　this.tx.commit();

　　// update some field(s) via direct JDBC call in another

　　// transaction. Assume that updatePersonNameViaJdbc()

　　// method will update version column as well

　　String newName = "Paul";

　　this.tx.begin();

　　updatePersonNameViaJdbc(pk, newName);

　　this.tx.commit();

　　// find CMP again and try to update name in yet

　　// another transaction

]]> Thu, 11 Mar 2010 10:03:40 GMT http://www.ltesting.net/images/defaultpic.gif WebLogic 秩名 领测软件测试网_专业软件测试工程师探讨软件测试技术第一门户 http://www.ltesting.net/ceshi/ruanjianceshikaifajishu/rjcskfyy/zjj/weblogi/2010/0310/169746.html 　　WebLogic Server中CMP实体bean的性能调优[5]   软件测试　

   　使用read-mostly模式

　　WebLogic Server通过将一个只读CMP bean和一个读写CMP bean映射到同一数据中为您提供了一个实现read-mostly模式的机制。您的应用程序应该用只读bean来读取数据，用读写bean来修改数据。只读bean按照上述部署描述符中read-timeout-seconds元素所指定的间隔从数据库中加载数据。为了保证只读bean总是返回当前数据，应该在读写bean更改数据时使只读bean无效。您可以通过在weblogic-ejb-jar.xml中的entity-descriptor小节的invalidation-target元素中指定该bean，来配置服务器，使其自动让相应的只读bean无效。这只能用于CMP 2.0实体bean。虽然该模式提供了缓存方面的好处，但是也有严重的不足。当使用该模式时，您应用程序中的大量实体bean将被有效地加倍，对应用程序的启动时间和内存造成影响。同样，开发人员需要记住，只读和读写操作应该使用不同的bean，这经常会令人混淆。

　　值得一提的是，在旧版本的WebLogic Server中(没有对只读模式的通过invalidation-target的内在支持)，仍可以使用它。回忆一下前面讲过的，根据EJB规范，如果EJB抛出一个RuntimeException或者它的子类物，容器就应该销毁bean实例。因此，可以在实体bean的只读版本上暴露这样的destroyMe()方法，并从读写bean的ejbStore()方法中调用它。这就是著名的sepukku模式。

　　在读/写CMP bean的事务间缓存

　　另一种更先进的长期缓存的方法是通过将weblogic-ejb-jar.xml中的cache-between-transactions元素设置为true来配置bean。这种情况下，只有客户端首先引用该bean或者事务被回滚时WebLogic Server才会调用ejbLoad()来从数据库中加载数据。

　　尽管从理论上说，您可以对除数据库并发之外的所有并发策略使用该方法，但是在实践中，只有对乐观并发使用该方法才有意义。当应用于只读并发时，该设置被忽略，因为bean数据已经被缓存;当应用于排他性并发时，只有EJB具有对底层数据库的排他性访问时才起作用，而这是极少出现的情况。此外，当具有排他性并发的bean被部署在集群中时，WebLogic Server自动禁用事务间的缓存，因为集群中的任何服务器都可能更新bean数据，并且没有用来在节点间同步或禁用缓存值的机制。这使得我们在进行长期缓存时只有一种可行的并发策略：乐观并发。

　　如前所述，对于利用乐观并发策略部署的bean，WebLogic Server有一种内在机制，用来通过verify-columns检测底层数据变更。虽然乐观并发本身只能为数据库并发带来少量性能改善，但可利用事务功能间的缓存提供更大的改善。如果在EJB缓存中bean实例已经可用的话，将cache-between-transactions设置为true将使WebLogic Server忽略对数据库的调用。对于某些类型的应用程序(其中同一对象在短期内被不同事务多次访问)，这可能导致显著的性能改善(在某些环境下，最多百分之30到40)。自然地，既然我们使用的是乐观并发，您的应用程序必须做好在检测到并发冲突时处理OptimisticConcurrencyException的准备。当OptimisticConcurrencyException(RuntimeException的子类型)被抛出时，WebLogic Server 从缓存中丢弃一个EJB实例。注意，如果您将delay-updates-until-end-of-tx设置为true(默认)，除非事务承诺否则就得不到乐观异常，并且如果使用的是容器受控事务这将在应用程序代码之外。

　　与read-mostly模式(不提供通知集群中其他节点其中一个节点的数据发生变更的机制)相比，当具有乐观并发的bean被更新时，一个通知将被广播给其他集群成员，并且缓存bean实例将被丢弃，以避免乐观冲突。由于WebLogic Server不广播数据变更本身，而是只广播某些种类的bean标识符，这种跨集群的缓存无效措施在提高性能和网络带宽利用率方面很有效。WebLogic Server自动完成这种缓存无效工作，bean开发人员不需要再做其他配置。当对同一个bean发出下一个请求时，新鲜的数据将被从数据库中加载。

　　使用read-mostly模式

　　WebLogic Server通过将一个只读CMP bean和一个读写CMP bean映射到同一数据中为您提供了一个实现read-mostly模式的机制。您的应用程序应该用只读bean来读取数据，用读写bean来修改数据。只读bean按照上述部署描述符中read-timeout-seconds元素所指定的间隔从数据库中加载数据。为了保证只读bean总是返回当前数据，应该在读写bean更改数据时使只读bean无效。您可以通过在weblogic-ejb-jar.xml中的entity-descriptor小节的invalidation-target元素中指定该bean，来配置服务器，使其自动让相应的只读bean无效。这只能用于CMP 2.0实体bean。虽然该模式提供了缓存方面的好处，但是也有严重的不足。当使用该模式时，您应用程序中的大量实体bean将被有效地加倍，对应用程序的启动时间和内存造成影响。同样，开发人员需要记住，只读和读写操作应该使用不同的bean，这经常会令人混淆。

　　值得一提的是，在旧版本的WebLogic Server中(没有对只读模式的通过invalidation-target的内在支持)，仍可以使用它。回忆一下前面讲过的，根据EJB规范，如果EJB抛出一个RuntimeException或者它的子类物，容器就应该销毁bean实例。因此，可以在实体bean的只读版本上暴露这样的destroyMe()方法，并从读写bean的ejbStore()方法中调用它。这就是著名的sepukku模式。

　　在读/写CMP bean的事务间缓存

　　另一种更先进的长期缓存的方法是通过将weblogic-ejb-jar.xml中的cache-between-transactions元素设置为true来配置bean。这种情况下，只有客户端首先引用该bean或者事务被回滚时WebLogic Server才会调用ejbLoad()来从数据库中加载数据。

　　尽管从理论上说，您可以对除数据库并发之外的所有并发策略使用该方法，但是在实践中，只有对乐观并发使用该方法才有意义。当应用于只读并发时，该设置被忽略，因为bean数据已经被缓存;当应用于排他性并发时，只有EJB具有对底层数据库的排他性访问时才起作用，而这是极少出现的情况。此外，当具有排他性并发的bean被部署在集群中时，WebLogic Server自动禁用事务间的缓存，因为集群中的任何服务器都可能更新bean数据，并且没有用来在节点间同步或禁用缓存值的机制。这使得我们在进行长期缓存时只有一种可行的并发策略：乐观并发。

　　如前所述，对于利用乐观并发策略部署的bean，WebLogic Server有一种内在机制，用来通过verify-columns检测底层数据变更。虽然乐观并发本身只能为数据库并发带来少量性能改善，但可利用事务功能间的缓存提供更大的改善。如果在EJB缓存中bean实例已经可用的话，将cache-between-transactions设置为true将使WebLogic Server忽略对数据库的调用。对于某些类型的应用程序(其中同一对象在短期内被不同事务多次访问)，这可能导致显著的性能改善(在某些环境下，最多百分之30到40)。自然地，既然我们使用的是乐观并发，您的应用程序必须做好在检测到并发冲突时处理OptimisticConcurrencyException的准备。当OptimisticConcurrencyException(RuntimeException的子类型)被抛出时，WebLogic Server 从缓存中丢弃一个EJB实例。注意，如果您将delay-updates-until-end-of-tx设置为true(默认)，除非事务承诺否则就得不到乐观异常，并且如果使用的是容器受控事务这将在应用程序代码之外。

　　与read-mostly模式(不提供通知集群中其他节点其中一个节点的数据发生变更的机制)相比，当具有乐观并发的bean被更新时，一个通知将被广播给其他集群成员，并且缓存bean实例将被丢弃，以避免乐观冲突。由于WebLogic Server不广播数据变更本身，而是只广播某些种类的bean标识符，这种跨集群的缓存无效措施在提高性能和网络带宽利用率方面很有效。WebLogic Server自动完成这种缓存无效工作，bean开发人员不需要再做其他配置。当对同一个bean发出下一个请求时，新鲜的数据将被从数据库中加载。

　　只读并发

　　最后一个并发策略是read-only并发。如果数据库中的某些表包含很少或从未被更改过的数据，那么就很有必要将CMP bean声明为只读。服务器仍然为每个事务激活一个新的bean实例，所以请求是并行处理的;它不会每次都调用ejbLoad()，但是根据read-timeout-seconds参数的值周期性地调用。这为您的应用程序带来了显著的性能提升，因为SQL选择只进行一次(第一次访问实体bean时)，然后就被缓存起来，在后面的事务中重用。

　　WebLogic Server 8.1 SP2之前版本中的一个特殊功能是，即使bean被部署为只读，开发人员仍然可以对该bean的实例进行create和remove操作。从8.1 SP2开始，这个功能在默认情况下已被禁用，但是如果您需要，可以通过在weblogic-cmp.jsr.xml中将allow-readonly-create-and-remove元素设置为true来打开它。

　　也有一种明确禁用只读实体bean的方法。该禁用操作强制在下一次事务开始时从数据库中刷新bean实例，即使读取时限还没过去。您可以将其看作冲洗实例缓存。可以使特定bean的一个特定实例，任何实例子集，或者给定bean的所有实例无效。要想调用invalidate()方法，您可能需要将bean的home或local home分别转换为CachingHome或CachingLocalHome。下面的代码说明了如何实现这一点：

　　Object o = context.lookup("MyBeanCMP");

　　// cast to CachinHome for remote interface or CachingLocalHome

　　// for local

　　CachingHome cachingHome = (CachingHome)o;

　　// invalidate particular instance by passing primary key value

　　cachingHome.invalidate(pk);

　　// invalidate any subset of bean instances by passing collections

　　// of primary keys

　　Collection pks = Array.asList(new Object[]{pk1, pk2, ...., pkN});

　　cachingHome.invalidate(pks);

　　// or invalidate all instances currently cached

　　cachingHome.invalidateAll();

　　当表中的数据准静态时(比如，如果它按照批处理过程每天更改一次)进行显式的无效操作很有用。这种情况下，您可以将相应的bean部署为只读，并且设置一个较大的读取超时值，然后，当批处理过程结束时，为这些实体bean调用invalidateAll()。

　　您可以通过在weblogic-ejb-jar.xml部署描述符中entity-cache一节中设置concurrency-strategy元素，为每个CMP bean指定一种并发策略。如果没有指定并发策略，WebLogic Server默认使用数据库并发。

　　性能改善策略

]]> Wed, 10 Mar 2010 10:48:35 GMT http://www.ltesting.net/images/defaultpic.gif WebLogic 秩名 领测软件测试网_专业软件测试工程师探讨软件测试技术第一门户 http://www.ltesting.net/ceshi/ruanjianceshikaifajishu/rjcskfyy/zjj/weblogi/2010/0310/169743.html 　　WebLogic Server中CMP实体bean的性能调优[3]  性能测试工具

　　乐观并发

　　乐观并发策略通过消除读取和更新操作之间数据库中的所有锁定解决了性能问题，同时还提供了检测更新丢失的机制。和数据库并发一样，乐观并发给每个事务一个自己的bean实例，但是它没有在事务进行过程中在EJB容器或数据库中包含任何锁。对于进行读锁定的数据库(非Oracle数据库)，容器在一个单独的事务(该事务在数据读取操作一完成就立即进行)中读取bean数据，从而避免了读取锁，并且提供了更高的可伸缩性。

　　这种更新丢失检测机制并不新鲜，在Java创建之前就已经存在好长时间了。该模式的基本思想简单而强大：在更新时，首先进行检查，以确定表中的数据在被第一个进程读取之后是否被其他进程修改。实际中，这通常是通过在update语句的where子句中包含一个或多个额外的“版本”列来实现的。下面给出了一个简单的SQL的例子，其中version列是一个数值，在每次更新操作之后会递增：

　　-- at Entity load time"container executes select of bean fields,

　　-- plus 'version' field

　　select name, address, version from person where person_id = 1;

　　-- container remember value read from version column,

　　-- say it was 123

　　-- at update time, value of version which was read previously

　　-- added to the where clause and version incremented

　　update person set name='Joe', version = version + 1 where person_id = 1 and version = 123;

　　在进行更新时，容器通过执行以下代码能检测出数据库中实际上有多少行被更新： 软件测试　　...

　　PreparedStatement ps =

　　connection.prepareStatement('update person...');

　　int rowsUpdated = ps.executeUpdate();

　　if (rowsUpdatated != 1) {

　　throw new OptimisticConcurrencyException('Data was modified by other process');

　　}

　　如您所见，该方法可使服务器避免更新丢失问题，并且不需要在容器或数据库中进行长期的锁定。该策略尤其适用于数据库中读取次数远多于更新次数，因此更新碰撞的几率很小时。通常，对于大部分应用程序来说是这样的。

　　一个用数字表示的版本列不是在WebLogic Server中实现乐观并发策略的唯一途径。相反可以使用一个时间戳列。(注意，数据库应该允许您存放足够精确的时间戳值)。时间戳的使用给您带来了额外好处，那就是知道记录的最后一次更新是什么时候。有时候在使用遗留数据库模式时，会不愿意或不可能更改数据表以添加一个版本列。这种情况下，WebLogic Server可以检查表中事务期间被读取的所有列(实体bean中的所有字段)，或者只检查被当前事务更新的列。乐观并发可用于遗留模式，无需对数据表进行任何修改，但是开销略微增加(意味着更复杂的SQL更新)。

　　数据库并发

　　数据库并发策略是目前WebLogic Server版本中的默认并发策略。它提供了数据持久性和性能间的折中考虑。原理很简单：WebLogic Server并不自己管理锁，而是为每个试图访问该bean的每个事务创建一个新的bean实例，并将并发控制和死锁检测委派给底层数据库。这就像多个客户端对单个数据库进行并行数据库操作;数据库的隔离水平和锁定策略将规定哪些更新、选择和插入会进行，按照何种顺序，以及哪些(如果有的话)会失败。直接好处是该策略在集群环境中的良好适用性——只要集群中的所有节点共享一个数据库，EJB容器就不需要为数据同步细节而烦恼。

　　该策略明显比排他性策略更具伸缩性，并且对于某些应用程序效果尤为出众，但是也无法摆脱一些严重的性能限制。即使这样，容器仍保持了一个实体bean实例池，并且这些实例不包含事务间的任何中间状态。这是实例池化而不是缓存数据。池化无状态实例的整体思想可能来自于早期的JVM实现，那时对象创建还是一项很昂贵的操作，并且从性能的角度来看缓存对象实例是有好处的。在现代的JVM中情况并非如此，因为大部分情况下对象的创建非常快，但是由于该行为是EJB规范中描述的，所有供应商都应支持它。然而，当使用数据库并发策略时，容器从缓存中取出“无状态的”bean实例，并且必须执行一条SQL选择操作以获得最新数据并填充实例字段。

　　这种方法可能还不错，因为我们不用担心“不新鲜的”bean实例(当数据库中的数据被从同一集群中的另一个节点或者从不同应用程序中更新时)，但是性能也同样受到明显影响。您总是在每次事务的开始以一个额外的select操作结束，即使您只是打算更新bean中的数据而对之前的值并不感兴趣。因此，在主要或仅是执行更新或插入操作的应用程序中使用实体bean意义不大——容器可能花大量时间做不必要的选择操作，然后再抛弃数据。

　　排他性和数据库并发策略至少存在一个共同问题：更新丢失的可能性。可以想象两个客户端几乎同时更新映射到一个实体bean的表中的同一条记录。如果数据库中没有锁，先完成的更新操作的结果会被其次完成的更新所覆盖。这是否是可接受的结果取决于您的业务需求。更新丢失通常是不可接受或者不想要的;因此，应用程序需要某种机制来避免或检测更新丢失的情况，并且有机会恢复。当应用程序部署再多个节点上时使用排他性策略将不能控制更新丢失问题。但是如我之前所述，您不应再考虑该该策略。

　　数据库策略通过将并发控制委派给数据库，提供了进行读数据操作时在数据库中使用排他性锁的选择。这是通过将weblogic-cmp-jar.xml中的use-select-for-update元素设置为true(默认为false)来实现的。顾名思义，该动作告诉WebLogic Server在加载实体bean数据时使用“select for update”。生成的数据库锁一致存在，直到事务完成，因此其他事务不可能在第一个事务运行期间读取或更改数据。该项技术也许在“select for update”上组合了“no wait”选项，可能解决更新丢失问题以及任何可能的死锁——只不过代价很高。

　　该方法的一个缺点是性能会降低，因为一旦一个事务锁住一个实体实例，其他事务就不能访问同样的实体数据，即使它们需要的是只读访问。这基本上就是另一种排他性策略，唯一的区别是这次它可用于集群环境，因为所有的锁定都发生在(共享)数据库中而不是服务器实例上。第二个缺点是bean的行为在某种程度上依赖于底层数据库的锁策略实现。比如，有些数据库支持细粒度、行级的锁定，而有些则不然。在后一种情况中，对整个记录页的访问可能被作为单个实体加载操作的结果而被阻止。

  　J2EE规范现在作为同时期企业项目的标准被广为接受。但是J2EE规范的一个重要部分即EJB持久性由于它的开发模型复杂并且实体bean的性能很差而长期受到批评。人们相信这样一个事实：如果实体bean(尤其是容器受控持久性实体bean，或者CMP)用于应用程序中，那么性能将受到影响。事实并非如此。

　　本文中我不打算解释EJB的复杂性。即将推出的EJB 3规范专门针对目标和开发模型，使得它更容易;该规范还提供依赖注入以及在实体bean容器之外的更容易的测试。相反，本文的目标在于提供BEA WebLogic Server 8.1和9.0中可用的高级选项的深度分析，使开发人员改善CMP bean的性能——在很多情况下可极大地改善。该主题很宽泛，不可能在一篇文章中一一涉及;因此，我只重点讨论CMP实体bean的并发以及长期缓存策略。我还简要说明了最新版本BEA WebLogic Server 9.0中的改进。

　　并发策略

　　J2EE开发人员知道EJB容器维护了一个实体bean缓存或者池，通常可在部署描述符中配置。令人惊奇的是，相当多的J2EE开发人员不知道这并不意味着一旦J2EE服务器从数据库中加载一个特定的bean实例，它就不再去数据库中寻找该实例，因为该实例已经保存在缓存池中了。相反，默认情况下J2EE服务器执行ejbLoad()在每次事务的开始从数据库中同步该实例的状态。基本上，CMP bean每运行一次(即使该bean在前一个事务中已经被加载)，服务器就执行一次SQL select语句来刷新它。只有在一个事务中操作多个实体bean实例时，服务器才会缓存它们。

　　显然，在每次事务中都重新从数据库中加载状态会造成很大的性能影响!这个默认行为很容易理解：如果数据库被多个进程共享，并且每个进程都可以改变数据库中持久对象的状态，那么这将是最安全的方法。但是可以通过告诉J2EE服务器保留事务间实体bean的缓存实例，从而避免大部分时间里从数据库中刷新数据来略微改善这种情况。为了解决这个问题并生成一个最优的解决方案，首先我将讨论BEA WebLogic Server中可用的不同的并发策略。

　　对于EJB开发人员来说很重要的一点是要知道实体bean中可用的不同并发策略。令人惊奇的是，有的开发人员甚至不知道并发选项的存在。那么适用于实体bean的并发策略是什么呢?EJB容器是一个高度多线程的应用程序，同时响应来自多个客户端的请求，这些请求通常会访问同一资源，比如数据表中的一行。因此，EJB容器应该管理对实体bean实例的并发访问;更加技术性地讲，并发策略决定了容器如何以及何时将实体bean的每个实例与底层数据库同步。

　　目前WebLogic Server中有四种可用的并发策略：排他、数据库、乐观和只读。默认情况下，从7.0版本开始，WebLogic Server就使用的是数据库并发。上面四种策略按性能从低到高依次排列。我将讨论每种策略的优缺点。

　　排他性并发

　　排他性并发意味着容器最多为每个主要键值创建一个实体bean实例(比如，表中的一行映射到容器中的一个EJB实例)。对指定实例的访问是串行的，并且请求是按照顺序逐个执行的。这种策略有一些严重的问题。首先，性能由于多个客户端对bean的串行访问受到明显影响，并且您不能再考虑应用程序的伸缩性。其次，EJB的单个实例(以及容器持有的关联锁)对于一个JVM(一个服务器实例)来说是本地的，不能在集群中工作。该策略只是用于后向兼容(早期版本的WebLogic Server默认使用它)，应该尽量不用。

   　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 Size为10时,数据库可能需要打开25*10=250个游标。不幸的是,当遇到与PreparedStatement Cache有关的应用程序错误时,你需要将Cache Size设置为0。

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

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

　　10) JSP调优

　　* 设置jsp-param pageCheckSeconds=-1;

　　* 设置serlet-reload-check=-1或ServletReloadCheckSecs=-1;

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

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

　　4) 调优执行队列线程;

　　a) 修改默认执行线程数

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

]]> Fri, 05 Feb 2010 10:13:54 GMT http://www.ltesting.net/images/defaultpic.gif WebLogic 秩名 领测软件测试网_专业软件测试工程师探讨软件测试技术第一门户 http://www.ltesting.net/ceshi/ruanjianceshikaifajishu/rjcskfyy/zjj/weblogi/2010/0205/169120.html 　　Weblogic服务器性能调优[1]   软件测试　

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

　　1) 设置JAVA参数;

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

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

　　* 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

　　3) 尽量开启本地I/O;

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

关键字：soa 最近我在为一个客户工作，他们有许多部署在WebLogic 8.1上的J2EE应用程序，需要我帮助他们把应用程序资产转化为SOA的服务资产。他们有严格的时限，所以不能对应用程序代码进行大的改动。在讨论中，他们不断提出关于Web服务的问题，我感觉人们通常将Web服务看作SOA的构件块。他们关注的是将应用程序组件转化为Web服务以及由此给整体环境和操作带来的影响。

    许多人将Web服务看作SOA基础架构的构件块，这并不奇怪。我认为Web服务可以是SOA的构件块，但并不一定是必需的。下面我将介绍为什么以及如何可以将部署在WebLogic Server上的应用程序组件看作作为SOA一部分的服务。

   应用程序可以被分解为实现业务功能的组件。每一个应用程序都有特定的业务、功能和操作需求。功能需求要迎合实现，在这方面我不准备花太多时间介绍，因为我们讨论的是已经成为企业一部分的、需要转化为SOA构件块的应用程序。此时我们需要关注的是，如何关联业务需求并为该应用程序提供一个轻松的操作环境。

    许多业务需求都归结为对应用程序的服务水平协议(SLA)的满足，业务需求可能包括以下方面:

    并发用户
    响应时间
    错误率
    工作负载优先化(业务功能按照优先级进行分解)
    应用程序采用率(就用户数目而言的应用程序扩展路线图)
    可用性

    操作需求与维护基础架构有关，可能包括以下方面:

    应用程序监控
    部署策略
    维护(补丁、升级)
    问题诊断

    大多数情况下，WebLogic实例上部署了许多应用程序，难以将上述需求关联到该环境中。

    隔离:给出上述场景之后，我们来看一种将这样的环境转化为SOA的一部分的方法。第一步是要隔离被认为是关键型的应用程序或组件。可以通过将这些应用程序部署到各自的WebLogic实例中，然后关联适当的存储器和WebLogic资源到该应用程序来实现隔离。然后这些服务器实例可以被集群化，这样就有助于进行故障转移，从而使环境具有高度可用性。不要忘记:业务期望值越高，基础架构的成本就越昂贵。如果需要隔离应用程序的特定组件，可以利用定制的执行队列(Execute Queue)或工作管理器(Work Manager)(9.0中的新特性)，为它们配置适当的线程数。创建执行队列可以为应用程序组件提供分离的请求通道，并防止请求缺乏关键型业务功能。在连接池级进行隔离可以确保数据库资源的可用性。

    服务器特征:我们需要从吞吐量、负载之下的响应等方面来了解服务器特征。这是通过进行负载/压力测试，然后调优环境以获得WebLogic Server实例的最佳性能指标来完成的。这是一项重要的任务，因为它可以帮助规划以后的应用程序采用率，从而提供一个可伸缩的环境。

]]> Thu, 27 Aug 2009 10:43:07 GMT http://www.ltesting.net/images/defaultpic.gif WebLogic 秩名 领测软件测试网_专业软件测试工程师探讨软件测试技术第一门户 http://www.ltesting.net/ceshi/ruanjianceshikaifajishu/rjcskfyy/zjj/tomcat/2009/0629/164061.html 性能测试时，一般都需要对应用服务器进行监控，监控的指标包括应用服务器的JVM使用状况、可用连接数、队列长度等信息。商业的应用服务器如WebLogic、WebSphere等都提供了Console对这些指标进行监控，在性能测试时可以很容易观察这些指标的情况。

　　Tomcat作为在国内得到广泛应用的J2EE服务器，在不少项目中都得到了使用。Tomcat小巧灵活、配置简单，非常适合小的WEB应用使用。但在对使用Tomcat的应用系统进行性能测试时，最头疼的问题就是不能获得应用服务器的相关性能指标数据。

　　其实，从Tomcat 5.0开始，Tomcat就已经为自己提供了一个用于监控应用服务器性能指标的servelet —— status servelet。安装完Tomcat 5之后，通过访问 http://yourhost:port/manager/status 就可以获得当时的应用服务器监控数据。

　　当然，为了安全起见，Tomcat 5在缺省安装时是不允许用户直接访问 http://yourhost:port/manager/status 的，访问的时候会给出一个403（forbidden）的错误信息。在Tomcat的Manual里说明了允许用户访问的方法：

   1. 转到Tomcat的安装目录下；
   2. 修改conf/tomcat-users.xml文件，在其中加入一行  <user username="servermon" password="passwd" roles="manager"/>

　　这样就可以在访问 http://yourhost:port/manager/status 时给出 servermon 的用户名与口令，查看到应用服务器的相关性能指标数据。
]]> Mon, 29 Jun 2009 10:45:13 GMT http://www.ltesting.net/images/defaultpic.gif tomcat 秩名 领测软件测试网_专业软件测试工程师探讨软件测试技术第一门户 http://www.ltesting.net/ceshi/ruanjianceshikaifajishu/rjcskfyy/zjj/tomcat/2009/0625/163988.html 性能测试时，一般都需要对应用服务器进行监控，监控的指标包括应用服务器的JVM使用状况、可用连接数、队列长度等信息。商业的应用服务器如WebLogic、WebSphere等都提供了Console对这些指标进行监控，在性能测试时可以很容易观察这些指标的情况。

　　Tomcat作为在国内得到广泛应用的J2EE服务器，在不少项目中都得到了使用。Tomcat小巧灵活、配置简单，非常适合小的WEB应用使用。但在对使用Tomcat的应用系统进行性能测试时，最头疼的问题就是不能获得应用服务器的相关性能指标数据。

　　其实，从Tomcat 5.0开始，Tomcat就已经为自己提供了一个用于监控应用服务器性能指标的servelet —— status servelet。安装完Tomcat 5之后，通过访问 http://yourhost:port/manager/status 就可以获得当时的应用服务器监控数据。

　　当然，为了安全起见，Tomcat 5在缺省安装时是不允许用户直接访问 http://yourhost:port/manager/status 的，访问的时候会给出一个403（forbidden）的错误信息。在Tomcat的Manual里说明了允许用户访问的方法：

   1. 转到Tomcat的安装目录下；
   2. 修改conf/tomcat-users.xml文件，在其中加入一行  <user username="servermon" password="passwd" roles="manager"/>

　　这样就可以在访问 http://yourhost:port/manager/status 时给出 servermon 的用户名与口令，查看到应用服务器的相关性能指标数据。
]]> Thu, 25 Jun 2009 10:16:36 GMT http://www.ltesting.net/images/defaultpic.gif tomcat 秩名 领测软件测试网_专业软件测试工程师探讨软件测试技术第一门户 http://www.ltesting.net/ceshi/ruanjianceshikaifajishu/rjcskfyy/zjj/tomcat/2009/0624/163953.html 一、Web集群的组成
    一个TongWeb Server集群包含有一定数量的TongWeb服务器、TongWebDirector 以及Web代理服务器。互相之间可以协作实现高负载，高可用性等功能。
    Web代理服务器（简称WebServer）：位于web客户端（浏览器）和TongWebDirector之间，可以是Microsoft IIS、Apache、NetScape/iPlanet。主要用于提供静态页面（html，gif，jpeg）服务，对于servlet/jsp的调用，将会转给TongWeb Director。
TongWeb Director：作为插件附加在Web代理服务器上。通过请求派发策略实现请求派发工作和服务器失效检测工作。
    TongWeb 服务器(AppServer)：之间可以通过网络实现对于http session数据的实时复制，从而保证客户端的高可靠访问。一台TongWeb服务器又称为一个集群节点。
    Web 应用：部署在TongWeb服务器上的，由 serlvet/jsp以及一些静态资源组成的应用程序，供浏览器访问使用。一个 web 应用，一般打包为一个 WAR 文件。

    Web代理服务器和TongWeb服务器启动的先后次序无关紧要，TongWebDirector将总是选择目前可用的TongWeb服务器，并周期性地检测TongWeb服务器是否正常工作。另外，还可以使用配置文件tongweb_director.conf来增加、删除或修改它所管理的TongWeb服务器。

二、Web集群的方式
1、负载均衡
    负载均衡是由多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，都可以单独对外提供服务而无须其他服务器的辅助。TongWeb集群通过代理服务器上的TongWebDirector，将客户端发送来的请求均匀分配到多台内部Web服务器之一上，从而达到负载均衡的目的。而接收到请求的服务器独立地回应客户的请求。
2、带会话迁移功能的应用级集群
    带会话迁移功能的应用级集群就是在建立的负载均衡集群的基础上增加了Session保存与迁移功能。当Web应用中使用了Session时，集群中的每个TongWeb服务器管理自己所产生的Session，当Web应用从一台服务器迁移到另一台服务器时，Session也会自动进行迁移，这样使得对Session的管理被均匀地分布到所有的服务器上，任何一台服务器失效并不会使Session数据丢失。从而保证了Session应用的安全性和可靠性。

三、在UNIX平台上用APACHE配置集群
1、TongWebDirector for Apache 1.3的安装配置
1.1 安装Apache Web Server
apache安装在10.46.6.181的/opt/apache目录下，用boss用户进入起停。
安装过程略（直接tar一个可用的就可以了）

1.2 修改配置
1）更改httpd.conf文件
进入/usr/local/apache/conf，使用熟悉的编辑工具如vi打开httpd.conf文件，修改ServerName和Port为自己需要的配置。
这里为了不影响大家原先的使用，所以将端口设置为9004

1.3 装载模块状态检查
为了后面能成功安装Apache上的TongWebDirector，必须确保mod_so能正常装载，因此需要检查模块是否装载，进入/usr/local/apache/bin，运行./httpd -l，查看是否有mod_so.c项，如果有就说明该正常装载了。

2、安装TongWebDirector二进制代码模块
2.1 安装所需二进制代码文件以及辅助文件列表
􀁺 Apache扩展模块文件： mod_tongweb_director.so
该文件是一个Apache扩展模块。缺省应该放在Apache的libexec目录，并使用httpd.conf中的AddModule和LoadModule指令装载。

􀁺 TongWebDirector 配置文件： tongweb_director.conf
该文件包含TongWebDirector配置。mod_tongweb_director.so模块缺省情况下在httpd.conf同一个目录中寻找该文件。

􀁺 TongWebDirector 守护程序文件: edir_daemon
该程序运行在后台监视模块子实例使用的共享内存区域来协调负载平衡。在Apache中必须是因为它使用多个单独进程来允许并发请求的多线程性。该守护进程在Apache启动时自动启动，并在Apache停止时自动清除共享内存退出。

􀁺 TongWebDirector 状态工具： edir_status
该实用程序直接读取TongWebDirector模块使用的共享内存区域，报告当前配置的每个应用和TongWeb服务器状态。
Director二进制模块是平台相关的，存放在/director/Apache目录中。