模板
教程
环境
性能
功能
管理
如何解决JAVA服务器性能问题
如何解决JAVA服务器性能问题 JAVA开发 摘要 改善JAVA服务器的性能需要模拟负载下的服务器。创建一个模拟环境、搜集数据并且分析结果可能是对许多开发人员的挑战。这篇文章中的示例介绍了JAVA服务器 性能分析 的概念和工具。作者使用这个示例来研究超额请求次
如何解决JAVA服务器性能问题 JAVA开发
摘要
改善JAVA服务器的性能需要模拟负载下的服务器。创建一个模拟环境、搜集数据并且分析结果可能是对许多开发人员的挑战。这篇文章中的示例介绍了JAVA服务器性能分析的概念和工具。作者使用这个示例来研究超额请求次数下内存使用和同步竟争的影响。
项目团队已经很熟悉如何组织一些具体的任务并完成他们。简单的性能问题很容易由一个开发人员分离并解决。然而大的性能问题，通常在系统处于高负载情况下发生，就不是这么简单能处理的了。这些问题需要一个独立的测试环境、一个模拟的负载，并且需要仔细地分析和跟踪。
在这篇文章中，我使用比较通用的工具和设备创建了一个测试环境。我会专注于两个性能问题，内存和同步，他们很难用简单的分析得到。通过一个具体的例子，我希望比较容易地解决复杂的性能问题而且可以提供处理问题过程中的细节。
改善服务器的性能
服务器的性能改善是依赖于数据的。没有可靠的数据基础而更改应用或环境会导致更差的结果。分析器提供有用的JAVA服务器应用信息，但由于从单用户负载下的数据与多用户负载下得到的数据是完全不同的，这导致分析器的数据并不精确。在开发阶段使用分析器来优化应用的性能是一个好的方式，但在高负载下的应用分析可以取到更好的效果。
在负载下分析服务器应用的性能需要一些基本的元素：
1、可控的进行应用负载测试的环境。
2、可控的人造负载使得应用满负荷运行。
3、来自监视器、应用和负载测试工具自身的数据搜集。
4、性能改变的跟踪。
不要低估最后一个需求（性能跟踪）的重要性因为如果不能跟踪性能你就不能实际的管理项目。性能上10-20%的改善对单用户环境来说并没有什么不同，但对支持人员来说就不一样了。20%的改善是非常大的，而且通过跟踪性能的改善，你可以提供重要的反馈和持续跟踪。
虽然性能跟踪很重要，但有时为了使后续的测试更加精确而不得不抛弃先前的测试结果。在性能测试中，改善负载测试的精确性可能需要修改模拟环境，而这些变化是必须的，通过变化前后的负载测试你可以观察到其中的转变。
可控的环境
可控的环境最少也需要两台独立的机器和第三台控制的机器。其中一台用来生成负载，另一台作为控制机与前一台建立测试应用并接受反馈，第三台机器运行应用。此外，负载和应用机器间的网络应该与局域网分开。控制机接受运行应用机器的反馈如操作系统、硬件使用率、应用（特别是VM）的状态。
负载模拟
最精确的模拟通常用实际的用户数据和WEB服务器端的访问日志。如果你还没有实际布署或者缺少实际的用户数据，你可以通过构造类似的场景或询问销售和产品管理团队或做一些有依据的猜想。协调负载测试和实际用户体验是一个持续的过程。
在模拟中一些用户场景是必须的。如在一个通用地址薄应用中，你应该区分更新和查询操作。在我的测试应用中GrinderServlet类只有一个场景。单用户连接10次访问这个servlet（在每一次访问间有一段暂停）。虽然这个应用很小，我认为这可以重复一些常见的东西。用户通常不会连接给服务器请求而没有间断。如果没有间断，我们可能不能得到更精确的实际用户上限。
串行10个请求的另一个原因是实际应用中不会只有一个HTTP请求。单一而又分离的请求可以影响环境中的许多因素。对Tomcat来说，会为每一个请求创建一个会话，并且HTTP协议允许不同的请求重用连接。我会修改一下负载测试来避免混洧。
GrinderServlet类不会执行任何排序操作，但这个需求在大部分应用中都很普通。在这些应用中，你需要创建模拟的数据集并且用他们来构造相关用例的负载测试。
例如，如果用例涉及到用户登录一个WEB应用，从可能的用户列表中选取随机的用户会只使用一个用户更精确。否则，你可能不经意地使用了系统缓存或其他的优化或一些微妙的东西，而这会使得结果不正确。
负载测试软件
负载测试软件可以构造测试场景并且对服务进行负载测试。我会在下面的示例中使用OpenSTA测试软件。这软件简单易学，结果也很容易导出，并且支持参数化脚本，还可以监视信息的变化，他的主要缺点是基于Windows，但在这儿不是个问题。当然还有很多可选项如Apache的JMeter和Mercury的LoadRunner。
监视
在生成合理的用户负载后，监视工具需要收集进程的运行状况。在我的测试环境中可以收集到各种有用的信息：
1、所有计算机、网络设备等等的使用率
2、JVM的统计数据。
3、个别JAVA方法所花费的时间。
4、数据库性能信息，包括SQL查询的统计。
5、其他应用相关的信息。
当然这些监视也会影响负载测试，但如果影响比较小也可以忽略。基本上如果我们想获取所有上面的信息，肯定会影响测试的性能。但如果不是一次获取所有信息还是有可能保证负载测试的有效性。仅对特定的方法设置定时器，仅获取低负载的硬件信息和低频率地获取样例数据。当然不加载监视器来做测试是最好的，然后和加载监视器的测试来做比较。虽然有时候侵入式监视是个好主意，但就不可能有监视结果了。
获取所有监视数据到一个中央控制器来做分析是最好的，但使用动态运行时工具也可以提供有用的信息。例如，命令行工具如PS、TOP、VMSTAT可以提供UNIX机器的信息；性能监视器工具可以提供WINDOWS机器的信息；而TeamQuest， BMC Patrol， SGI's Performance Co-Pilot， and ISM's PerfMan这样的工具会在所有的测试环境中的机器安装代理并且将需要的信息传回中央控制机，这样就可以提供文本或可视化的信息。在本文中，我使用开源的Performance Co-Pilot作为测试统计的工具。我发现他对测试环境的影响最小，并且以相对直接的方式来提供数据。
JAVA分析器提供很多信息，但通常对负载测试来说影响太大而没有太多的用处。工具甚至可以让你在负载服务器上做一些分析，但这也很容易便测试无效。在这些测试中，我激活了详细的垃圾收集器来收集内存信息。我也使用jconsole 和jstack工具（包含在J2SE 1.5中）来检查高负载下的VM。我没有保留这些测试用例中负载测试的结果因为我认为这些数据不是很正确。
同步瓶颈
在诊断服务器问题时线程的信息是非常有用的，特别是对同步之类的问题。jstack工具可以连接到运行的进程并且保存每一个线程的堆栈信息。在UNIX系统可以用信号量3来保存线程的堆栈信息，在WINDOWS系统的控制台中可以用Ctrl-Break。在第一项测试中，jstack指出许多线程在grindCPU()方法中被阻塞。
你可以已经注意到列表2中grindCPU()方法的同步修饰符实际上并不必须。我在后一项测试中删除了他，如图2显示
改善JAVA服务器的性能需要模拟负载下的服务器。创建一个模拟环境、搜集数据并且分析结果可能是对许多开发人员的挑战。这篇文章中的示例介绍了JAVA服务器性能分析的概念和工具。作者使用这个示例来研究超额请求次数下内存使用和同步竟争的影响。
项目团队已经很熟悉如何组织一些具体的任务并完成他们。简单的性能问题很容易由一个开发人员分离并解决。然而大的性能问题，通常在系统处于高负载情况下发生，就不是这么简单能处理的了。这些问题需要一个独立的测试环境、一个模拟的负载，并且需要仔细地分析和跟踪。
在这篇文章中，我使用比较通用的工具和设备创建了一个测试环境。我会专注于两个性能问题，内存和同步，他们很难用简单的分析得到。通过一个具体的例子，我希望比较容易地解决复杂的性能问题而且可以提供处理问题过程中的细节。
改善服务器的性能
服务器的性能改善是依赖于数据的。没有可靠的数据基础而更改应用或环境会导致更差的结果。分析器提供有用的JAVA服务器应用信息，但由于从单用户负载下的数据与多用户负载下得到的数据是完全不同的，这导致分析器的数据并不精确。在开发阶段使用分析器来优化应用的性能是一个好的方式，但在高负载下的应用分析可以取到更好的效果。
在负载下分析服务器应用的性能需要一些基本的元素：
1、可控的进行应用负载测试的环境。
2、可控的人造负载使得应用满负荷运行。
3、来自监视器、应用和负载测试工具自身的数据搜集。
4、性能改变的跟踪。
不要低估最后一个需求（性能跟踪）的重要性因为如果不能跟踪性能你就不能实际的管理项目。性能上10-20%的改善对单用户环境来说并没有什么不同，但对支持人员来说就不一样了。20%的改善是非常大的，而且通过跟踪性能的改善，你可以提供重要的反馈和持续跟踪。
虽然性能跟踪很重要，但有时为了使后续的测试更加精确而不得不抛弃先前的测试结果。在性能测试中，改善负载测试的精确性可能需要修改模拟环境，而这些变化是必须的，通过变化前后的负载测试你可以观察到其中的转变。
可控的环境
可控的环境最少也需要两台独立的机器和第三台控制的机器。其中一台用来生成负载，另一台作为控制机与前一台建立测试应用并接受反馈，第三台机器运行应用。此外，负载和应用机器间的网络应该与局域网分开。控制机接受运行应用机器的反馈如操作系统、硬件使用率、应用（特别是VM）的状态。
负载模拟
最精确的模拟通常用实际的用户数据和WEB服务器端的访问日志。如果你还没有实际布署或者缺少实际的用户数据，你可以通过构造类似的场景或询问销售和产品管理团队或做一些有依据的猜想。协调负载测试和实际用户体验是一个持续的过程。
在模拟中一些用户场景是必须的。如在一个通用地址薄应用中，你应该区分更新和查询操作。在我的测试应用中GrinderServlet类只有一个场景。单用户连接10次访问这个servlet（在每一次访问间有一段暂停）。虽然这个应用很小，我认为这可以重复一些常见的东西。用户通常不会连接给服务器请求而没有间断。如果没有间断，我们可能不能得到更精确的实际用户上限。
串行10个请求的另一个原因是实际应用中不会只有一个HTTP请求。单一而又分离的请求可以影响环境中的许多因素。对Tomcat来说，会为每一个请求创建一个会话，并且HTTP协议允许不同的请求重用连接。我会修改一下负载测试来避免混洧。
GrinderServlet类不会执行任何排序操作，但这个需求在大部分应用中都很普通。在这些应用中，你需要创建模拟的数据集并且用他们来构造相关用例的负载测试。
例如，如果用例涉及到用户登录一个WEB应用，从可能的用户列表中选取随机的用户会只使用一个用户更精确。否则，你可能不经意地使用了系统缓存或其他的优化或一些微妙的东西，而这会使得结果不正确。
负载测试软件
负载测试软件可以构造测试场景并且对服务进行负载测试。我会在下面的示例中使用OpenSTA测试软件。这软件简单易学，结果也很容易导出，并且支持参数化脚本，还可以监视信息的变化，他的主要缺点是基于Windows，但在这儿不是个问题。当然还有很多可选项如Apache的JMeter和Mercury的LoadRunner。
监视
在生成合理的用户负载后，监视工具需要收集进程的运行状况。在我的测试环境中可以收集到各种有用的信息：
1、所有计算机、网络设备等等的使用率
2、JVM的统计数据。
3、个别JAVA方法所花费的时间。
4、数据库性能信息，包括SQL查询的统计。
5、其他应用相关的信息。
当然这些监视也会影响负载测试，但如果影响比较小也可以忽略。基本上如果我们想获取所有上面的信息，肯定会影响测试的性能。但如果不是一次获取所有信息还是有可能保证负载测试的有效性。仅对特定的方法设置定时器，仅获取低负载的硬件信息和低频率地获取样例数据。当然不加载监视器来做测试是最好的，然后和加载监视器的测试来做比较。虽然有时候侵入式监视是个好主意，但就不可能有监视结果了。
获取所有监视数据到一个中央控制器来做分析是最好的，但使用动态运行时工具也可以提供有用的信息。例如，命令行工具如PS、TOP、VMSTAT可以提供UNIX机器的信息；性能监视器工具可以提供WINDOWS机器的信息；而TeamQuest， BMC Patrol， SGI's Performance Co-Pilot， and ISM's PerfMan这样的工具会在所有的测试环境中的机器安装代理并且将需要的信息传回中央控制机，这样就可以提供文本或可视化的信息。在本文中，我使用开源的Performance Co-Pilot作为测试统计的工具。我发现他对测试环境的影响最小，并且以相对直接的方式来提供数据。
JAVA分析器提供很多信息，但通常对负载测试来说影响太大而没有太多的用处。工具甚至可以让你在负载服务器上做一些分析，但这也很容易便测试无效。在这些测试中，我激活了详细的垃圾收集器来收集内存信息。我也使用jconsole 和jstack工具（包含在J2SE 1.5中）来检查高负载下的VM。我没有保留这些测试用例中负载测试的结果因为我认为这些数据不是很正确。
同步瓶颈
在诊断服务器问题时线程的信息是非常有用的，特别是对同步之类的问题。jstack工具可以连接到运行的进程并且保存每一个线程的堆栈信息。在UNIX系统可以用信号量3来保存线程的堆栈信息，在WINDOWS系统的控制台中可以用Ctrl-Break。在第一项测试中，jstack指出许多线程在grindCPU()方法中被阻塞。
你可以已经注意到列表2中grindCPU()方法的同步修饰符实际上并不必须。我在后一项测试中删除了他，如图2显示
