+1
0

性能与伸缩性

jametong 发表于 2010年04月12日 13:14 | Hits: 2472
Tag: Translation | scale up | My Reading | scalability | throuthput | scale-out

本文是Werner Vogels针对其”A word on Scalability“的评论所做的回应,为Scalability的定义新增了性能与运维效率等维度的说明.
关于a word on scalability的翻译可以参见此文:简述伸缩性
本文原文链接为:Performance and Scalability

性能与伸缩性
ByWerner Vogels,Translated By: Jametong

在简述伸缩性这篇文章中,我尽可能为伸缩性给出一个比它日常使用时更加精确的定义.这篇文章后面的评论以及The ServerSide的讨论中还有很多关于此定义的较好的评论.

我先以一种不太精确的方式回顾一下我给出的定义:

  • 当我们往一个系统中新增资源时,它带来的性能提升与新增的资源量保持一定的比例关系,我们才认为此服务具备伸缩性.
  • 对于一个永远在线的服务来讲,伸缩性意味着为促进冗余而增加的资源不会导致相应的性能损失。
  • 一个具备伸缩性的服务需要能够处理异构的资源

有很大一部分评论认为伸缩性的定义中应该涵盖性能的维度.下面就是我如何在此情境中考虑性能维度的原因:我假设每个服务都有一个对应的SLA(Service Level Agreement,服务级别协议)合约来定义你的客户对此服务的预期.SLA中具体如何定义取决于商业需要哪种级别的服务;对于一个Amazon.com这样的网站来讲,有很大一部分服务的SLA是等待时间(latency )驱动的.这个等待时间会有一个特定的分布,你从这个分布区间中提取一个有代表性的时间来衡量你的SLA.例如,在Amazon,我们跟踪99.9%这个点上的等待时间,以确保几乎所有的客户都能取得等于或好于SLA的体验.

如果业务出现增长,这个SLA也必须得到保持.增长可能意味着请求数的增长、服务项目数量的增长、或者每次请求所需工作量的增长,如此等等.但是,不管朝着哪个方向增长, 你都需要确保总是可以满足你的SLA.系统沿着某些方向增长或许可以通过使用更快的CPU或者更大的内存以向上扩展(scale up )的方式实现,如果系统持续的增长,通过不断的购买更大更强的设备来向上扩展总会有尽头,这时你将不得不选择向外扩展(scale out ).考虑到向上扩展通常更不经济,你不妨现在就开始考虑向外扩展,因为你最终将不得不走上这条路.

我很少看到纯粹吞吐量(throughput )驱动的SLA.常见的情况都是基于后续三点的一个综合,需要完成的工作量、这些工作量到达的时间分布、以及这些工作需要完成的时间点,这些情况综合起来导致了一个吞吐量驱动的SLA.等待时间也在此扮演的一个角色,因为确定需要什么样的吞吐量才能实现对应的输出分布区间,它通常都是其中的驱动因素。如果系统请求的到达分布不均匀,只要可以接受更长的等待时间,你就可以通过缓冲或设置一个低于峰值的吞吐量上限来达到目的。通常都是想要实现的这个等待时间的分布决定了吞吐量的需求。

关于伸缩性的定义还应包含哪些内容,讨论中还涉及一些其他问题,给出较好建议的人包含Gideon Low(我尝试连接到他个人的回应,但似乎做不到).

  • 运维效率-随着硬件数量的增长,仅需要耗费较少的人力资源来管理此系统。
  • 自修复能力-增加资源的数量也会增加这些资源中的一个出错的概率,但是出现故障的影响应该随着资源数量的增加而下降。

这两点与之前关于代价/容量/效率(cost /capacity /efficiency )的讨论一起都应该成为一个服务伸缩性定义的一部分。我将再深入思考下用什么合适的词语来表达此定义,并给出后续的建议。

No related posts.

原文链接: http://item.feedsky.com/~feedsky/dbthink/~8068730/368254236/6175071/1/item.html

0     +1

我要给这篇文章打分:

可以不填写评论, 而只是打分. 如果发表评论, 你可以给的分值是-5到+5, 否则, 你只能评-1, +1两种分数. 你的评论可能需要审核.

评价列表(1)

  • +1 admin voted at 2010-04-12 19:09:33