吞吐量的确定

      不管业务程序设计的如何优秀，优异表现总是在一定的吞吐量范畴之内，当超过吞吐量限制之后性能必然会产生变异。在衡量性能的时候，确定吞吐量就成为一个基础性工作。
      吞吐量的候选指标：
      Transaction,Execute,User call，后两个吞吐量指标是在11g中才发布的，估计Oracle也认识到了transaction的不可比较性，所以增加了Execute和User call两个吞吐量指标。
      事实上，稍微考虑一下，Execute和transaction类似，都是只有在业务模式完全固定的情况下才具有可比较性。同样是100个执行或者100个transaction，其响应时间和消耗资源会完全不同。而我们几乎不太可能在两个不同的时间范围之内获得完全相同比例规模的Transaction数量或者Execute数量。
      User Calls或者Calls（Users calls+recursive calls）则比较Execute和transaction的可比较性要高很多，尤其是在处理Parse的时候，Calls具有相当大的精确性和可比较性。虽然对于Oracle User Call缺乏研究，但可以相信虽然比较Transaction和Execute具有更加可比较性，用来衡量吞吐量具有更好的效果。但相信不同User call的成本应该还是区别比较大的。
      在数据库处理阶段，我们选择了Logical IO和Physical IO来衡量吞吐量，尤其是Logical IO。为什么选择Logical IO作为基准SQL工作吞吐量是合适的：
     1、任何SQL Call都会产生Logical IO，Call成本的不同体现为Logical IO的不同，即使是纯粹的Parse操作。
     2、除了direct IO之外，Oracle任何操作都需要通过SGA区域进行，任何SGA区域操作都会标记为Logical IO。

      为什么选择LIO和PIO，主要原因为LIO是一个相对稳定的指标，在配置正确的情况下其服务时间主要依赖于CPU和内存的速度，而随着并发量的增加对于LIO的服务时间并没有太大的影响，主要在于增加了Queue Time。
      在LIO基础之上的吞吐量曲线公式变化为：
     
      每个LIO的响应时间：= LIO服务时间 + LIO Queue Time
      而吞吐量就标记为：LIO的数量 lio/s。
      后续有时间会制作一个LIO的实际吞吐量响应曲线。
 
   

physical read IO requests

8,635

28.54

0.89每个

    我们看以下主要的吞吐量指标（50 User tpcc）：
    Statistic                                     Total     per Second     per Trans
    DB time                                         125,300        414.1          13.0
    CPU used by this session            1,421            4.7           0.2
    session logical reads                   959,193        3,169.7          99.4

    recursive calls                             252,672          835.0          26.2
    user calls                                     8,381              27.7           0.9    
    user commits                                9,631             31.8           1.0
    execute count                              203,508          672.5          21.1  
 
   DB time                                         115,965          454.8          17.3  
   CPU used by this session             2,775            10.9           0.4
   session logical reads                    1,247,177      4,891.0         186.5

   execute count                               140,102          549.4          21.0
   recursive calls                               211,764          830.5          31.7
   user calls                                       7,636           30.0           1.1
   user commits                                  6,682           26.2           1.0

    DB time                                       359,901          1,189.0          19.1 
    CPU used by this session           2,799              9.3           0.2
    session logical reads                 1,800,672        5,948.9          95.6

    execute count                               387,949        1,281.7          20.6
    recursive calls                             475,718        1,571.6          25.3
    user calls                                     15,131           50.0           0.8
    user commits                                18,791           62.1           1.0

   

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/92650/viewspace-775384/，如需转载，请注明出处，否则将追究法律责任。