数据库性能基准的5个问题

情况。假设你那样做，问题变成你如何分析这样的基准结果，并准确确定那台服务器的最大并发用户负载。图表4显示了TPC-C基准的结果，只在一台服务器上确定拐点（即用户负载开始对响应时间有负面影响）。

图4

如果你的最终用户要求响应时间（最常见的指标）少于2秒，那么在200个并发用户这个点你应该停下来。图4显示这个服务器可支持多达250个用户并发直到响应时间达到无法接受的急骤上升的点. 在这种情况下，TPS比率开始趋于平缓或减少，这个例子中碰巧，这两个点同时出现。但是并不总是如此明显;这是因为有时两个拐点并不一定排列的这么整齐。当拿不准时，建议通常关注TPC-C或OLTP类型事务的响应时间。

5.如何确定一个服务器所能支持的最大数据仓库大小?

这又是一个很难回答的问题，因为大多数人想听到是，“处理X千兆字节的数据需要一台Dell 1850。”上文中提到，比较服务器是不容易的事情，除非你拥有的主机几乎有一样的配置，以及一样的网络和磁盘I/O环境。磁盘I/O在这里是特别重要的，因为TPC-H结果大部分是由磁盘数量来决定的。如果能比较服务器，那么问题就变为如何从基准结果中确定那台指定服务器的最大数据仓库的大小。在图表5中，显示了基于几个强大的Oracle RAC服务器配置的TPC-H基准的测试结果。这些服务器访问分布在多个SAN和超过100个磁盘上的300GB数据。

图5

在TPC-H中，值得注意的是，应该同时关注整体运行时和间平均响应时间。TPC-H的询问是非常复杂的，通常要花数个小时，或好几天才能完成。

根据图表6，最好的硬件配置大运行5小时，平均响应时间约4小时。然而，通过几次运行时间很长的测试，实际的响应时间的变化是很倾斜的。因此，如果你的用户对于高度复杂的决策支持查询能接受运行时间在4个小时的，8个节点的集群将可以满足要求。如果不能接受的话，那么需要购买更多磁盘，而不是增加更多的服务器。对于千兆容量的数据仓库，使用500到1000个磁盘可以达到最佳的效果，这种情况并不少见。

图5

 

来自：http://blog.csdn.net/xuejinyoulan/archive/2007/10/25/1843766.aspx