下面是15个很有用的工具，能够帮助你开发更快的web工具

 

1. YSlow for Firebug

YSlow 能够评价一个网站的性能，基于Yahoo! Developer Network 的 best practices for high performance web sites . 每一条规则都从A-F打分，综合评定你的网站是否合理的进行了性能优化。比如你是否合理减少了每个页面HTTP request的次数，是否队CSS和JS文件进行了压缩等。你可以阅读 Ajax performance analysis 来学习如何使用 YSlow .

2. Firebug

 

Firebug 是一个优秀的基于浏览器的web开发工具，调试，测试，分析web页面，firefox用户一定不会陌生。

3. Fiddler 2

Fiddler 2 是一个基于浏览器的HTTP调试工具 ，帮助你分析进入和出去的traffic。用户可以进行设置，查看报表和调试细节。可以阅读MSDN上的 “Fiddler PowerToy - Part 2: HTTP Performance” 学习如何分析HTTP request。

4. Cuzillion

Cuzillion 是一个很酷的工具，帮助你查看页面组件的交互，目标是帮助你在结构化页面的时候快速检查，测试和编辑web页面。它会给你提供线索在一些基础性的问题上。可以配合YSlow一起使用.

5. mon.itor.us

monitor.us 是一个基于web的免费服务，提供给你一套工具来监控性能状况，网站是否可链接，以及traffic情况。

6. IBM Page Detailer

The IBM Page Detailer 是一个直接可视化查看正在下载的web组件的工具。

7. Httperf

Httperf 是一个开源工具，调节Linux下 HTTP server 性能。

8. Pylot

Pylot 是一个开源性能和扩展工具。

9. PushToTest TestMaker

PushToTest TestMaker 是一个免费开源的平台来测试扩展和性能的工具。类似Pylot。

10. Wbox HTTP testing tool

Wbox is 是一个简单的免费工具，来测试 HTTP 软件，在 GPL (v2) 下.

11. WebLOAD

WebLOAD is 是一个开源专业工具，使用JavaScript测试性能和代码。

12. DBMonster

DBMonster 是一个开源应用，帮助你调节数据库和表索引，并且监控数据库的性能那。支持的数据库包括： MySQL, PostgreSQL, Oracle, MSSQL and (probably) any database that supports the JDBC driver.

13. OctaGate SiteTimer

The OctaGate SiteTimer 是一个简单的下载时间检测工具。可视化的看出页面所有内容被下载的现状。

14. Web Page Analyzer

The Web Page Analyzer 是一个可以扩展的简单基于web的测试工具，帮助你查看网站情况。

15. Site-Perf.com

Site-Perf.com 是一个免费的基于web的测试服务，帮助你查看网站的加载时间。

安装TPTP

　　安装TPTP最容易的方式是使用Remote Update站点（参见图1）。打开Remote Update窗口（Help -> Software Updates -> Find and Install），然后选择Callisto Discovery Site。Eclipse将建议安装Callisto插件集。TPTP工具列在“Testing and Performance”下面。最容易也是最耗时的选择，就是安装所有建议的插件。即使不安装整个Callisto工具集，您仍然需要安装一些其他 TPTP需要的组件，例如"Charting and Reporting"、"Enabling Features"和"Data Tool Performance"。

　　 图 1.从远程站点安装TPTP

分析Java应用程序

　　测试与性能工具平台基本上是一套分析工具。分析应用程序通常涉及到观察应用程序在压力之下的处理方式。这样做的一种常见方式是对已部署的应用程 序运行一组负载测试，然后使用分析工具来记录应用程序的行为。接着，可以对结果进行研究来调查任何性能问题。这些事情通常是在项目结束时进行的，因为此时 应用程序几乎已经准备好进入生产阶段了。

　　TPTP非常适合这类任务。一个典型的用例是使用像JMeter这样的工具来运行负载测试，然后使用TPTP归纳工具记录和分析性能统计数据。

　　然而，这并非使用TPTP分析应用程序的唯一方式。通常，越早进行测试，后面遇到的问题就越少。借助TPTP，您可以在很多上下文中分析代码，包括JUnit测试用例、Java 应用程序和web应用程序。而且它很好地集成到了Eclipse IDE中。所以，没有理由不在早期开始初步性能测试和分析工作。

　　TPTP让您可以测试应用程序行为的几个方面，包括内存使用（创建了多少对象，这些对象的大小如何）、执行统计数据（应用程序在哪些地方所花的时间较多）和测试覆盖（测试期间执行代码的确切数量）。每个方面均可提供有关应用程序性能的独立信息。

　　不管怎么说，内存泄漏可能而且的确存在于Java中。创建（并保存）不必要的对象会增加对内存的需求，并加重垃圾收集器的工作负担，这都会损害 应用程序的性能。而且，如果运行应用程序的服务器的持续正常运行时间很长，累积下来的内存泄漏可能最终导致应用程序崩溃或服务器停止运行。这些都是留心应 用程序内存泄漏情况的充分理由。

　　根据80-20经验法则，80%的性能问题出现在20%的代码中。或者，换句话说，只要把精力集中在应用程序中执行最经常的部分上，就可以花费相对较少的气力使性能有实质性的提高。在这种情况下，执行统计数据就可以派上用场了。

　　除此以外，TPTP还提供一些基本的测试覆盖数据。尽管这些统计数据不如Cobertura或Clover这样的专用工具提供的完整，您仍然可以通过它们快速了解性能测试正在有效地测试哪些方法。

　　在本文中，我讨论的测试种类同样是没有经过优化的。优化涉及到使用像缓冲这样的技术对应用程序性能进行微调。这是一项对技术要求很高的操作，最好留到项目的最后完成。

　　这里所讨论的这种初步性能测试和分析仅仅包括，确保应用程序从一开始就正确执行，以及没有编码错误或糟糕的编码实践会在后面的阶段中对性能产生不利的影响。事实上，修复内存泄漏和避免不必要的对象创建并不是优化——这只不过是调试，而且同样应该尽可能早地完成。

　　让我们通过使用一些单元测试来分析一个类的方式开始。可以分析常规的单元或集成测试，或者编写针对性更强的面向性能的测试。通常，您应该尝试分 析与生产代码最接近的代码。许多人使用模拟对象来代替DAO对象进行单元测试，使用这项功能强大的技术可以加速开发生命周期。如果使用这类方法，一定要使 用这些测试来运行分析工具，它可以揭示有关内存使用和测试覆盖的有用信息。然而，性能测试的价值是有限的，因为对于与数据库相关的应用程序来说，其性能往 往是由数据库的性能所决定的，所以在这个上下文中，应该进行所有重要的性能测试。简而言之，不要忘了分析基于实际数据库而运行的集成测试。

　　出于本文的需要，我们将对以下类进行测试，这个类代表了一个到库目录的简单接口。

interface Catalog {
    List<Book> findBooksByAuthor(String name);
    List<Book> findAllBooks();
}

　　基本的单元测试如下：

public class CatalogTest extends TestCase {
    ...
    public Catalog getCatalog() {
        ...
    }

    public void testFindBooksByAuthor() {
        List<Book> books = getCatalog().findBooksByAuthor("Lewis");
    }

    public void testLoadFindBooksByAuthor() {
        for(int i = 0; i < 10; i++) {
            List<Book> books
                = getCatalog().findBooksByAuthor("Lewis");
        }
    }

    public void testFindAll() {
        List<Book> books = getCatalog().findAllBooks();
    }
}

　　您需要做的第一件事情就是建立一个分析。在Eclipse主菜单中选择"Run -> Profile"，这将打开一个向导，您可以在其中配置不同种类的测试分析，如图2所示。

　　图 2. 创建一个TPTP分析

　　在这个例子中，我们感兴趣的是JUnit测试分析。双击这一项；向导应该为每个单元测试类创建新的项。TPTP相当灵活，您可以在此屏幕中配置 各个选项。例如，在Test选项卡上，可以单独分析单元测试类，也可以按照项目或软件包对它们进行分组。在Arguments选项卡上，可以指定运行时参 数，而在Environment选项卡上可以定义环境变量。在Destination选项卡中，可以指定一个外部文件，用于保存分析数据以供以后使用。但 是，最有用的是Monitor选项卡（参见图3），可以在上面指定要记录和研究的性能相关数据：

• Basic Memory Analysis（基本内存分析）：这个选项用于记录内存使用的统计数据，包括对象实例的数量和已经使用的全部内存。
• Execution Time Analysis（执行时间分析）：这个选项用于记录性能数据——即应用程序分别在每个方法上所花的时间长短。
• Method Code Coverage（方法代码覆盖）：这个选项用于通知在测试期间执行了哪些类和方法。

　　 图 3: 在Monitor选项卡上定义要记录数据的类型。

　　您可以直接从这个窗口运行分析工具，也可以使用位于要分析的测试类上的上下文菜单，方法是选择Profile As菜单项（参见图4）。

　　图 4:可以使用上下文菜单运行TPTP分析工具。

　　运行分析具可能要花上一段时间，这取决于测试用例的大小。完成之后，Eclipse将显示一个Profiling Monitor视图，可以在其中显示每种类型分析的结果的详细信息（参见图5）。

　　图 5: 分析结果

　　Memory Statistics视图显示了应用程序创建的对象的数量。结果可以按照软件包来组织（以树视图的形式），或者显示为类或实例的一个列表。这些数据可以让您了解每种类型创建了多少个对象；应该对创建的对象（特别是高级对象，例如域对象）不正常的高数量持怀疑态度。

　　用于检测内存泄漏的另一个有用工具是Object References视图。为了获得这些数据，您需要激活引用收集。启动分析之后，点击monitoring项，然后在上下文菜单中选择Collect Object References（参见图6）。接下来，通过上下文菜单（Open with -> Object References）打开Object References视图。您将获得一个类的列表，它带有对每个类的引用的次数。这可以为可能的内存泄漏提供一些线索。

　　图 6: 激活引用收集

　　如图7所示，从Execution Statistics视图可以清楚地了解到应用程序执 行到了哪里。"organization by"软件包可以帮助您找出执行时间最长的类和方法。点击一个方法将打开Method Invocation Details视图，它将显示有关方法被调用次数、调用地点以及它本身调用了哪些其他方法的更详细信息。尽管与一些可以向下发掘到源代码本身的商业工具相 比，这个视图与源代码视图的集成度没有那么高，但是它还是可以给出一些重要线索，帮助您找出执行错误的方法。

　　图 7: Execution Statistics视图

　　Coverage Statistics视图（参见图8）提供的信息是关于，您刚刚运行的测试用例使用了（因此至少在某种程度上测试了）哪些方法。覆盖统计数据是一项优秀的 功能，尽管它们提供的信息的详细程度还无法与像Cobertura、Clover和jcoverage这样的专业覆盖工具相提并论（它们可以提供行精度的 覆盖数据，以及行和分支覆盖的统计数据）。尽管如此，它也有自身的优点，那就是可以提供实时的覆盖结果，而目前，只有商业的代码覆盖工具，例如Clover和jcoverage，才能提供行级别的覆盖报告和完整的IDE集成。

　　图 8: Coverage Statistics视图

静态分析工具

　　在TPTP工具箱中，另一件有趣的工具就是静态分析工具。Java静态分析工具，例如PMD，允许通过基于一组代码预定义规则和最佳实践检查来检查代码，从而自动验证代码质量。现在，TPTP也包含一个静态分析工具。除了提供它自己的一组静态分析规则之外，这个工具还可以提供一个一致的接口，其他工具厂商可以在这个接口中集成他们自己的规则。

　　要对代码进行静态分析，需要创建分析配置。在Java视图或Analysis图标中，使用上下文菜单打开Analysis窗口，它现在应该出现 在工具栏上（参见图9）。分析配置决定了要分析的代码（Scope）和应该遵循的规则（Rules）。有71条规则可供选择，例如"Avoid casting primitive types to lower precision"和"Always provide a break at the end of every case statement"。您还可以使用预定义的规则，例如"Java Quick Code Review"（在这里，71条规则中只有19条适用）。

　　图 9:建立静态分析规则

　　要分析代码，使用工具栏中的Analysis图标。分析不是实时完成的，就像一些其他的类似工具一样，例如Checkstyle。然而，给出的 结果很清晰（参见图10）：错误在源代码视图中标出，并且按照错误类型，以树视图的形式在Analysis Results视图中列出。"Quick Fix"是一项优雅的特性，它出现在错误类型的上下文菜单中，而且如果可能，它可以自动为您纠正问题。

　　图 10: 静态代码分析结果

结束语

　　Eclipse测试与性能工具平台是Eclipse IDE工具箱中极具价值的部分。它支持的性能测试的范围很宽，这有助于从第一个单元测试开始，就确保获得高质量和高性能的代码。

　　TPTP无疑还比不上一些可用的商业工具，例如OptimizeIt和JProbe，后者的报告和分析功能要更加完善，而且表示通常更加精练。 然而，商业的分析工具往往非常昂贵，而且很难在最严峻的环境中来验证它们的使用情况。尽管TPTP还相对较为不成熟，它仍然可算作一款功能强大的产品，毋 庸置疑，它可以提供对于许多项目来说不可或缺的有价值的分析数据。

From BEA CN

安装TPTP

　　安装TPTP最容易的方式是使用Remote Update站点（参见图1）。打开Remote Update窗口（Help -> Software Updates -> Find and Install），然后选择Callisto Discovery Site。Eclipse将建议安装Callisto插件集。TPTP工具列在“Testing and Performance”下面。最容易也是最耗时的选择，就是安装所有建议的插件。即使不安装整个Callisto工具集，您仍然需要安装一些其他 TPTP需要的组件，例如"Charting and Reporting"、"Enabling Features"和"Data Tool Performance"。

　　 图 1.从远程站点安装TPTP

分析Java应用程序

　　测试与性能工具平台基本上是一套分析工具。分析应用程序通常涉及到观察应用程序在压力之下的处理方式。这样做的一种常见方式是对已部署的应用程 序运行一组负载测试，然后使用分析工具来记录应用程序的行为。接着，可以对结果进行研究来调查任何性能问题。这些事情通常是在项目结束时进行的，因为此时 应用程序几乎已经准备好进入生产阶段了。

　　TPTP非常适合这类任务。一个典型的用例是使用像JMeter这样的工具来运行负载测试，然后使用TPTP归纳工具记录和分析性能统计数据。

　　然而，这并非使用TPTP分析应用程序的唯一方式。通常，越早进行测试，后面遇到的问题就越少。借助TPTP，您可以在很多上下文中分析代码，包括JUnit测试用例、Java 应用程序和web应程序。而且它很好地集成到了Eclipse IDE中。所以，没有理由不在早期开始初步性能测试和分析工作。

　　TPTP让您可以测试应用程序行为的几个方面，包括内存使用（创建了多少对象，这些对象的大小如何）、执行统计数据（应用程序在哪些地方所花的时间较多）和测试覆盖（测试期间执行代码的确切数量）。每个方面均可提供有关应用程序性能的独立信息。

　　不管怎么说，内存泄漏可能而且的确存在于Java中。创建（并保存）不必要的对象会增加对内存的需求，并加重垃圾收集器的工作负担，这都会损害 应用程序的性能。而且，如果运行应用程序的服务器的持续正常运行时间很长，累积下来的内存泄漏可能最终导致应用程序崩溃或服务器停止运行。这些都是留心应 用程序内存泄漏情况的充分理由。

　　根据80-20经验法则，80%的性能问题出现在20%的代码中。或者，换句话说，只要把精力集中在应用程序中执行最经常的部分上，就可以花费相对较少的气力使性能有实质性的提高。在这种情况下，执行统计数据就可以派上用场了。

　　除此以外，TPTP还提供一些基本的测试覆盖数据。尽管这些统计数据不如Cobertura或Clover这样的专用工具提供的完整，您仍然可以通过它们快速了解性能测试正在有效地测试哪些方法。

　　在本文中，我讨论的测试种类同样是没有经过优化的。优化涉及到使用像缓冲这样的技术对应用程序性能进行微调。这是一项对技术要求很高的操作，最好留到项目的最后完成。

　　这里所讨论的这种初步性能测试和分析仅仅包括，确保应用程序从一开始就正确执行，以及没有编码错误或糟糕的编码实践会在后面的阶段中对性能产生不利的影响。事实上，修复内存泄漏和避免不必要的对象创建并不是优化——这只不过是调试，而且同样应该尽可能早地完成。

　　让我们通过使用一些单元测试来分析一个类的方式开始。可以分析常规的单元或集成测试，或者编写针对性更强的面向性能的测试。通常，您应该尝试分 析与生产代码最接近的代码。许多人使用模拟对象来代替DAO对象进行单元测试，使用这项功能强大的技术可以加速开发生命周期。如果使用这类方法，一定要使 用这些测试来运行分析工具，它可以揭示有关内存使用和测试覆盖的有用信息。然而，性能测试的价值是有限的，因为对于与数据库相关的应用程序来说，其性能往 往是由数据库的性能所决定的，所以在这个上下文中，应该进行所有重要的性能测试。简而言之，不要忘了分析基于实际数据库而运行的集成测试。

　　出于本文的需要，我们将对以下类进行测试，这个类代表了一个到库目录的简单接口。

interface Catalog {
    List<Book> findBooksByAuthor(String name);
    List<Book> findAllBooks();
}

　　基本的单元测试如下：

public class CatalogTest extends TestCase {
    ...
    public Catalog getCatalog() {
        ...
    }

    public void testFindBooksByAuthor() {
        List<Book> books = getCatalog().findBooksByAuthor("Lewis");
    }

    public void testLoadFindBooksByAuthor() {
        for(int i = 0; i < 10; i++) {
            List<Book> books
                = getCatalog().findBooksByAuthor("Lewis");
        }
    }

    public void testFindAll() {
        List<Book> books = getCatalog().findAllBooks();
    }
}

　　您需要做的第一件事情就是建立一个分析。在Eclipse主菜单中选择"Run -> Profile"，这将打开一个向导，您可以在其中配置不同种类的测试分析，如图2所示。

　　图 2. 创建一个TPTP分析

　　在这个例子中，我们感兴趣的是JUnit测试分析。双击这一项；向导应该为每个单元测试类创建新的项。TPTP相当灵活，您可以在此屏幕中配置 各个选项。例如，在Test选项卡上，可以单独分析单元测试类，也可以按照项目或软件包对它们进行分组。在Arguments选项卡上，可以指定运行时参 数，而在Environment选项卡上可以定义环境变量。在Destination选项卡中，可以指定一个外部文件，用于保存分析数据以供以后使用。但 是，最有用的是Monitor选项卡（参见图3），可以在上面指定要记录和研究的性能相关数据：

• Basic Memory Analysis（基本内存分析）：这个选项用于记录内存使用的统计数据，包括对象实例的数量和已经使用的全部内存。
• Execution Time Analysis（执行时间分析）：这个选项用于记录性能数据——即应用程序分别在每个方法上所花的时间长短。
• Method Code Coverage（方法代码覆盖）：这个选项用于通知在测试期间执行了哪些类和方法。

　　 图 3: 在Monitor选项卡上定义要记录数据的类型。

　　您可以直接从这个窗口运行分析工具，也可以使用位于要分析的测试类上的上下文菜单，方法是选择Profile As菜单项（参见图4）。

　　图 4:可以使用上下文菜单运行TPTP分析工具。

　　运行分析工具可能要花上一段时间，这取决于测试用例的大小。完成之后，Eclipse将显示一个Profiling Monitor视图，可以在其中显示每种类型分析的结果的详细信息（参见图5）。

　　图 5: 分析结果

　　Memory Statistics视图显示了应用程序创建的对象的数量。结果可以按照软件包来组织（以树视图的形式），或者显示为类或实例的一个列表。这些数据可以让您了解每种类型创建了多少个对象；应该对创建的对象（特别是高级对象，例如域对象）不正常的高数量持怀疑态度。

　　用于检测内存泄漏的另一个有用工具是Object References视图。为了获得这些数据，您需要激活引用收集。启动分析之后，点击monitoring项，然后在上下文菜单中选择Collect Object References（参见图6）。接下来，通过上下文菜单（Open with -> Object References）打开Object References视图。您将获得一个类的列表，它带有对每个类的引用的次数。这可以为可能的内存泄漏提供一些线索。

　　图 6: 激活引用收集

　　如图7所示，从Execution Statistics视图可以清楚地了解到应用程序执 行到了哪里。"organization by"软件包可以帮助您找出执行时间最长的类和方法。点击一个方法将打开Method Invocation Details视图，它将显示有关方法被调用次数、调用地点以及它本身调用了哪些其他方法的更详细信息。尽管与一些可以向下发掘到源代码本身的商业工具相 比，这个视图与源代码视图的集成度没有那么高，但是它还是可以给出一些重要线索，帮助您找出执行错误的方法。

　　图 7: Execution Statistics视图

　　Coverage Statistics视图（参见图8）提供的信息是关于，您刚刚运行的测试用例使用了（因此至少在某种程度上测试了）哪些方法。覆盖统计数据是一项优秀的 功能，尽管它们提供的信息的详细程度还无法与像Cobertura、Clover和jcoverage这样的专业覆盖工具相提并论（它们可以提供行精度的 覆盖数据，以及行和分支覆盖的统计数据）。尽管如此，它也有自身的优点，那就是可以提供实时的覆盖结果，而目前，只有商业的代码覆盖工具，例如Clover和jcoverage，才能提供行级别的覆盖报告和完整的IDE集成。

　　图 8: Coverage Statistics视图

静态分析工具

　　在TPTP工具箱中，另一件有趣的工具就是静态分析工具。Jva静态分析工具，例如PMD，允许通过基于一组代码预定义规则和最佳实践检查来检查代码，从而自动验证代码质量。现在，TPTP也包含一个静态分析工具。除了提供它自己的一组静态分析规则之外，这个工具还可以提供一个一致的接口，其他工具厂商可以在这个接口中集成他们自己的规则。

　　要对代码进行静态分析，需要创建分析配置。在Java视图或Analysis图标中，使用上下文菜单打开Analysis窗口，它现在应该出现 在工具栏上（参见图9）。分析配置决定了要分析的代码（Scope）和应该遵循的规则（Rules）。有71条规则可供选择，例如"Avoid casting primitive types to lower precision"和"Always provide a break at the end of every case statement"。您还可以使用预定义的规则，例如"Java Quick Code Review"（在这里，71条规则中只有19条适用）。

　　图 9:建立静态分析规则

　　要分析代码，使用工具栏中的Analysis图标。分析不是实时完成的，就像一些其他的类似工具一样，例如Checkstyle。然而，给出的 结果很清晰（参见图10）：错误在源代码视图中标出，并且按照错误类型，以树视图的形式在Analysis Results视图中列出。"Quick Fix"是一项优雅的特性，它出现在错误类型的上下文菜单中，而且如果可能，它可以自动为您纠正问题。

　　图 10: 静态代码分析结果

结束语

　　Eclipse测试与性能工具平台是Eclipse IDE工具箱中极具价值的部分。它支持的性能测试的范围很宽，这有助于从第一个单元测试开始，就确保获得高质量和高性能的代码。

　　TPTP无疑还比不上一些可用的商业工具，例如OptimizeIt和JProbe，后者的报告和分析功能要更加完善，而且表示通常更加精练。 然而，商业的分析工具往往非常昂贵，而且很难在最严峻的环境中来验证它们的使用情况。尽管TPTP还相对较为不成熟，它仍然可算作一款功能强大的产品，毋 庸置疑，它可以提供对于许多项目来说不可或缺的有价值的分析数据。

From BEA CN

• 内存存储数据页、内部数据结构和过程缓存。
  
• 计数器监视 SQL Server 读取和写入数据库页时的物理 I/O。
  

监视 SQL Server 使用的内存和计数器有助于确定：

• 是否存在物理内存不足的瓶颈。如果 SQL Server 无法将经常访问的数据存储在缓存中，则必须从磁盘检索数据。
  
• 是否可以通过添加更多内存或增加数据缓存或 SQL Server 内部结构的可用内存来提高查询性能。
  
• SQL Server 需要从磁盘读取数据的频率。与其他操作（例如内存访问）相比，物理 I/O 会消耗大量时间。尽可能减少物理 I/O 可以提高查询性能。
  

还可以使用地址窗口化扩展插件 (AWE) 计数器来监视 SQL Server 中的 AWE 活动。例如，可以确保 SQL Server 有足够的内存分配给 AWE，以使其正确运行。有关详细信息，请参阅内存体系结构、使用 AWE或 awe enabled 选项。

下表描述了 SQL Server Buffer Manager 性能对象。

       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 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 > 配置下面几项：

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

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

6) 改变Java编译器；

标准的Java编译器是javac，但编译JSP servlets速度太慢，为了提高编译速度，可以使用sj或jikes编译器取代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 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/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html。

10) JSP调优

l         设置jsp-param pageCheckSeconds=-1；

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

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

 

]]> 6559112@http://zeeslo.bokee.com/ 软件测试 2007-12-07T18:43:15Z http://zeeslo.bokee.com/6559099.html
SGA几个很重要的特性：
1、SGA的构成——数据和控制信息，我们下面会详细介绍；
2、SGA是共享的，即当有多个用户同时登录了这个实例，SGA中的信息可以被它们同时访问（当涉及到互斥的问题时，由latch和enquence控制）；
3、一个SGA只服务于一个实例，也就是说，当一台机器上有多个实例运行时，每个实例都有一个自己的SGA尽管SGA来自于OS的共享内存区，但实例之间不能相互访问对方的SGA区。

它主要包括：
1.数据库高速缓存(the database buffer cache)，
2.重演日志缓存（the redo log buffer）
3.共享池（the shared pool）
4.数据字典缓存（the data dictionary cache）以及其它各方面的信息。

1.数据高速缓冲区（Data Buffer Cache）

    在数据高速缓冲区中存放着Oracle系统最近使用过的数据块（即用户的高速缓冲区），当把数据写入数据库时，它以数据块为单位进行读写，当数据高速缓冲区填满时，则系统自动去掉一些不常被用访问的数据。如果用户要查的数据不在数据高速缓冲区时，Oracle自动从磁盘中去读取。数据高速缓冲区包括三个类型的区：1） 脏的区（Dirty Buffers）：包含有已经改变过并需要写回数据文件的数据块。
2） 自由区（Free Buffers）：没有包含任何数据并可以再写入的区，Oracle可以从数据文件读数据块该区。
3） 保留区（Pinned Buffers）：此区包含有正在处理的或者明确保留用作将来用的区。

2.Redo Log Buffer Cache缓存对于数据块的所有修改。
主要用于恢复其中的每一项修改记录都被称为redo 条目。利用Redo条目的信息可以重做修改。

3. Shared Pool用于缓存最近被执行的SQL语句和最近被使用的数据定义。
它主要由两个内存结构构成：Library cache和Data dictionary cache
修改共享池的大小：ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;
   
   Libray Cache缓存最近被执行的SQL和PL/SQL的相关信息。实现常用语句的共享，使用LRU算法进行管理，由以下两个结构构成：Shared SQL area、Shared PL/SQL area、Data Dictionary Cache、Data dictionary cache缓存最近被使用的数据库定义。它包括关于数据库文件、表、索引、列、用户、权限以及其它数据库对象的信息。在语法分析阶段，Server Process访问数据字典中的信息以解析对象名和对存取操作进行验证。数据字典信息缓存在内存中有助于缩短响应时间。

4.数据字典缓存（the data dictionary cache）
它包括的信息有：数据库文件，表，索引，列，用户，权限和其他数据对象，在解析间段，服务器进程查看数据字典来决定对象名称和有效的访问的信息，缓存数据字典信息来提高请求反应时间，大小是由共享池的大小来决定的。

]]> 6559099@http://zeeslo.bokee.com/ 其他资料 2007-12-07T18:23:02Z