提高J2EE层与数据库层交互操作能力优势 - 编程入门网
问题就是应该受到责备的。查找起因的一个方法是让APM工具显示应用程序发出的所有SQL语句，按照响应时间进行排序，这样你就可以看到某个SQL语句是否因为出错的原因花费了太长时间（有些SQL语句会花费很长时间——例如按帐户检索一年内所有事务的列表）。
提高J2EE层与数据库层交互操作能力优势(2)时间:2010-12-23现在你查看一下位于列表顶部的SQL语句。它进入数据库并花费了1秒钟响应。这样的性能不是太差；如果这是性能最差的SQL语句，那么问题可能根本不在SQL语句中。因此，接下来的问题是：是不是应用程序层出了什么问题呢？谁在调用这个语句？调用了多少次？如果某个应用程序调用SQL语句的次数超过了你的预期，你就有理由怀疑应用程序出了故障。 APM工具这次又可以帮助你了。你可以简单地点击该SQL语句，会出现一个链接，显示出它的整个调用树，从顾客请求帐户概要信息开始，到进入数据库的SQL语句为止。现在你拥有了两部分信息：你能肯定自己在查看该服务请求的某个特定请求；你可以看到每个独立的组件对响应时间的影响。 现在你可以查看调用该SQL语句的组件说明，并且你发现它的响应时间是9秒钟。很明显，它是造成客户等待15秒钟的主要因素。APM工具显示的列表同时显示出这个组件7次调用了该SQL语句。这就告诉你9秒中大部分是调用SQL语句消耗的。该组件不仅执行了过多的计算，还多次调用了SQL语句。这样的操作可能有些很好的原因，但是任何性能管理工具都不能说明其起因。最重要的是你已经指出了必须进行调查的程序组件。良好的APM工具还可以为解决这个问题提供一些建议。 真的是数据库的问题吗？ 让我们从另一个角度来看这个问题。假设该组件并没有多次调用SQL语句，它只调用了一次，但是这次调用却消耗了15秒中的大部分。现在的问题是，为什么单个语句需要那么长时间执行呢？这个问题不在代码中，因此它可能在数据库那一端。 你现在需要的是性能管理工具允许你对特定服务请求（获取帐户概要信息）的调查深入到数据库层。请返回你得到的SQL语句列表，点击你感兴趣的SQL语句的链接，它会把你从J2EE端带到数据库端。现在你在查看Oracle数据库或其它数据库产品环境中的SQL语句。该工具可能帮助你查明数据库端的问题，还可能提供一些专业的调整建议，数据库管理员（DBA）可以使用这些建议来提高数据库的性能。问题可能出在存放数据表空间的磁盘性能较差，建议把它移动到另一个磁盘上；也可能是丢失了某个索引，你可以通过建立新索引来提高速度；也许是数据库上并行运行了太多的线程，你必须对这些线程进行隔离以减少并发性问题。 还有其它一些可能性。数据检索可能花费太多的时间，因为花费了很长时间等待获取数据库连接。代码是良好的，数据库运行也正常，但是这样的等待时间可能告诉你数据库连接池不够大，无法处理大量的甚至于正常的通讯。你可以查询应用程序服务器，了解已经定义了多少个连接，把这个数字与典型的并发请求数进行对比，很快就可以确定是否需要更多的连接了。 提高交互操作能力 你的性能管理工具不仅需要识别出J2EE层响应时间的构成因素。它还应该能够让你看到J2EE层和相邻的数据库层之间的交互操作情况，并为分析这两个层次上的性能问题提供方法。为了高效率地处理性能问题，J2EE开发者和DBA使用综合的APM产品是必要的。它同时还让J2EE和数据库小组"用同一种语言说话".大多数APM解决方案的目标都是架构体系中的单个层次，为单个层次提供诊断信息。使用这种方法的时候，时间会浪费、相互的责备会形成风暴、而且经常还是无从解决问题。今天复杂的架构和老练的技术意味着某个层次与其它层次之间的交互操作所导致的性能问题用这种途径是无法定位的。现在我们能够使用的 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
