频道栏目
读书频道 > 数据库 > Oracle > Oracle性能预测
2.2.4 事务流
2013-09-04 11:44:47     我来说两句
收藏   我要投稿

本文所属图书 > Oracle性能预测

本书共10章。第1章介绍了性能预测的基本概念和范畴,分析了预测提供的信息及其价值;第2章介绍了基本的性能预测概念,深入研究了如何组合及建模性能预测;第3章介绍了提高预测精度的一些有效手段,通过选择合适的...  立即去当当网订购

我们已经讨论了到达、事务处理器和队列,现在,让我们来讨论事务流程。当某个业务的事务被提交时,它在整个计算系统中流动并消耗CPU、IO、内存和网络资源。有时事务并没有在队列中等待,可以立即得到处理,有时,它必须先在队列中等待。但关键是,事务流在整个系统中,多次地排队和被处理,直到它完成并退出系统。

在某个事务的生命周期内,如果我们将所有的服务时间和排队时间累加起来,就可以判断出事务在系统中花费的时间。这个“系统中的时间”通常被称为响应时间。响应时间是预测中最重要的术语,也是最简单的一个术语。响应时间是服务时间加上排队时间:

在精确地定义到底什么是服务时间和排队时间时出现了混乱。请记住,服务时间是事务实际被服务的时间,而事务的排队时间是除了等待被服务,什么都不做的时间。人们很容易将这些定义描述得过于简单化,而没有真正的价值。不要被愚弄了。

虽然一位Oracle DBA会将服务时间、CPU时间和其他一切时间都当作排队时间,但并不是每个人都认为响应时间是这样的。IO子系统的工程师可能将服务时间看作数据传输时间,而将旋转延迟和磁盘磁头的移动时间作为排队时间。内存专家对服务时间和排队时间也有自己的定义。人们感觉将响应时间关联到他们自己的参照系是最舒适的。这更容易理解。

但是,在想要和你的参照系以外的人交流时,就会出现问题。所以,在讨论响应时间和将你所认为的服务时间和排队时间传授给你的听众时,你必须非常小心。

大多数模型专注于单个的计算系统组件。例如,可以专门为CPU子系统建模,对于一个IO子系统或网络子系统也是一样。虽然这可能是完全适当的,但要明白单组件的方法通常不会和多组件的方法一样精确。多组件模型比单组件模型更复杂,通常用于和预测相关的产品。

当真正的事务进入真正的系统时,它不会进入CPU队列,等待,得到CPU的服务,然后退出系统。实际情况显然要比这复杂得多。该事务可能先进入CPU子系统,然后进入IO子系统,再返回到CPU子系统,最后再退出。在每个事务的生命周期中都有一个事件链,有反馈,还会有许多我们没有处理的细节情况发生。这也没关系,只要我们的模型捕捉到了足够有用的实际情况即可。

在进行性能预测时,我们密切关注输入(服务时间和服务器的数量)和输出(排队时间、排队长度、利用率、响应时间)。这些数据是我们分析的基础。使用绘制曲线图来传达这些数据是一种极好的方式。本书中多次引用的最常见的曲线图,称为响应时间曲线。

您对本文章有什么意见或着疑问吗?请到论坛讨论您的关注和建议是我们前行的参考和动力  
上一篇:2.2.3 队列
下一篇:2.3 响应时间曲线
相关文章
图文推荐
排行
热门
最新书评
特别推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站