知名网站的技术实现

Posted on

知名网站的技术实现

BlueDavy之技术blog

{互联网,OSGi,Java, High Scalability, High Performance,HA}

知名网站的技术实现

Jun 14

bluedavy互联网 低成本, 可伸缩性, 可用性, 性能 No Comments 在上一篇《知名网站的技术发展历程》中,介绍了一些知名网站在发展的过程中技术的演变,在这篇文章中则会根据这些网站的发展经验,来总结通常网站是如何来应对可伸缩性、可用性、高性能以及低成本这四方面的挑战的。

在上一篇文章中,介绍了一些Alexa排名较前的网站的技术发展历程,在这篇文章中,将结合提及到的网站的技术发展历程,来总结下网站在可伸缩性、可用性、高性能以及低成本四点上通常采用的技术。 对于一个网站而言,最重要的是要支撑住不断增长的访问量和数据量,如果能做到简单的增加机器即可支撑,那自然是最好的,但这就要求技术上必须付出一定的努力,这也是网站都追求的可伸缩性(Scalability),而在做到可伸缩性后,不断增加的机器也带来了成本的上升,因此发展到了一定规模后,成本也会成为关注的重点。 除了可伸缩性外,可用性对于各网站而言也非常重要,一个经常不能使用的网站必被用户抛弃,这也是为什么各网站都很强调全年的可用性。 除了上面这三点外,还有另外一点影响也很明显,就是性能,美国的一个对网站访问速度的调查数据:1/4的用户因为一个网站载入的时间超过4秒而放弃这个网站,50%的手机用户会放弃一个超过10秒还没载入完成的网站,其中的3/5用户将不再光顾这个网站,而Google对其数据分析后,发现搜索结果只要慢1/4秒,一天的搜索量就要减少800万。

可伸缩 可伸缩分为垂直伸缩和水平伸缩,垂直伸缩为通过升级机器的硬件来解决问题,水平伸缩为通过增加机器来解决问题,不同网站在可伸缩上采用了不同的策略,例如Google完全依赖水平伸缩来解决问题,而其他网站多数是先依赖垂直伸缩来解决数据存储的问题。 垂直伸缩要求的是软件上要能在硬件升级的情况下,发挥出硬件的能力,例如可配置的并行数、内存等,硬件的发展速度非常迅猛,网站的机器的配置自然也是每年都在升级,因此其实我们的软件时刻都在被检验是否能垂直伸缩。 水平伸缩主要要解决的是如何做到仅通过增加机器就解决问题,主要又分成了应用层和存储层两个层次来解决。 在应用层要做到水平伸缩,通常采用的策略是Share Nothing/Stateless,状态信息放入客户端或存储层(例如用户的Session信息放入Cookie,或放入服务器端的缓存系统),应用系统做到了无状态,那么在访问量上涨后只需要增加机器即可,在应用系统由单台增加到多台组成Cluster时,这时就会有负载均衡的引入,可能是硬件的也可能是软件的。 在应用层的结构演变上,我们会发现,随着网站的不断发展,以上提到的各家网站在应用层上最后形成的结构几乎都完全一样,均为前端Web系统Cluster + Services Cluster,前端Web系统和Services到了一定的阶段后通常又会按照一定的规则来进行拆分,如按业务领域等,可见SOA其实在大网站中是落地了的,而不像企业领域中宣传的那么虚。 在存储层要做到水平伸缩,难度就比应用层大多了,从前面各家网站的发展历程也可看出,很多时候都在解决存储层的问题,而且可以看出,很多网站由于业务发展的压力较大,一开始都会选择采用垂直伸缩的方式来解决存储层的问题。 存储层主要是Cache、文件和数据三种类型。 Cache可以看到基本上各家网站都采用了Memcache来保证伸缩性,在规模大了,也会碰到一些问题,具体可以看看facebook所做的改造,现在也有些网站开始采用redis了,但redis本身不具备可伸缩性,需要自行进行改造。 文件的存储可以看到各家网站都采用了分布式文件系统来保证伸缩性,思路多数都源于GFS,但由于存储的文件的大小不同、对响应时间和吞吐量的要求不同,各家网站可能都各自实现。 数据的存储上可以看到各家网站基本都采用了分库分表的策略,分库分表后由于很多关系型数据库的特性(例如自增ID、join、事务等)都难以再使用了,对应用的设计会带来一些挑战,不过最大难点还是在于需要根据业务来考虑如何分是合适的,在最近几年也有一些网站开始采用NoSQL来更好的做到数据存储的可伸缩性。 存储层为了做到可伸缩性,通常采用的方案是单点写(是指在某个粒度的单点,例如对HBase而言,是单行数据一定是在同一台机器上进行写操作),但读可能是多点,读多点的话主要要考虑不一致的问题,无论读是单点还是多点,数据都会在软件层面做到写多份,策略主要有同步写多份、投票写多份、异步复制最终一致等(例如HDFS、Cassandra、Zookeeper),采用自动分裂的方法来实现数据量增长时的自动伸缩,采用一致性hash或根据某种规则的自动balance策略等来实现机器增减时的相应处理,同时也需要有感知机器增减的方法(例如采用zookeeper)。 从上面可以看到存储层上要做到可伸缩,技术上的难点很多,这也是为什么大规模的网站都不在数据库上做复杂的运算,而只是把其当做一种存储来使用,例如存储过程这种就更是基本不会出现了,以降低数据库的压力。 除了应用层和存储层需要做到可伸缩外,硬件层面的可伸缩在设计系统时也是需要考虑的,例如硬件负载设备只能支撑到一定的流量,同样也需要考虑如何让其能够可伸缩。 除了尽可能做到系统可伸缩外,减少对系统的压力也是缓解系统的可伸缩面临挑战的方法,例如批量提交、最终一致、youtube提到的“欺骗”、适当的正确性等策略。 可伸缩性是网站从小到大要经历的第一关挑战,而且随着网站的不断发展,还要不断的做技术改造才能保证网站在每个不同的阶段(例如同机房阶段、同城多机房阶段、异地多机房阶段)都具备优秀的可伸缩性,不过幸运的是不同阶段的可伸缩性方案都已经比较成熟。

可用性 可伸缩性保证了网站在不断增长的访问量和数据量的情况下生存下来,这也一定程度保证了网站的可用性,但除了这点外,要保障系统的可用性,还得付出很多的努力。 在设计高可用性的系统时,避免单点是其中最重要的一点,通常采用主备和集群的方法来避免单点,例如负载均衡设备、MySQL等通常采用主备的方式,在BigTable里采取了一种比较特殊的方法来避免Tablet Server的单点:通过Chubby来感知Tablet Server的健康状况,如发现Tablet Server挂掉了,则由Master将此Tablet Server负责的Tablet迁移到其他的Tablet Servers上。 除了避免单点外,降低耦合也是设计高可用性系统时应考虑的重点,通常可以采取异步化来降低耦合,将非关键逻辑和关键逻辑隔离开,例如在淘宝上买一件商品,确认购买了后,需要旺旺通知卖家,如果旺旺通知卖家这个过程是同步通知的话,对于系统来说无疑增加了一个风险点,因此可以将旺旺通知卖家的步骤变为异步的方式来做,这种场景的异步通常又采用消息中间件来实现;还有另外一种场景也经常采用异步化的方式来降低耦合,例如打开天猫的商品详情时,都会有相关商品的推荐,如果这个推荐系统出问题的话,就会导致商品详情也看不到了,因此这里也可以采用异步化来加载推荐系统,在这种场景中通常采用Ajax带超时的方式来实现。 各网站在总结多年的可用性系统设计的经验时,有一个设计原则被所有网站列入:保持简单,简单的方案意味着容易掌控,而复杂的方案一方面意味着实现难度大,另一方面意味着出现问题时很难排查。 可控性也是各网站强调的重点,可控性就意味着一切的代码都在掌握下,并且最好是每个使用到的部分都有专业的人士(对可用性要求越高,在这点上要求也就越高),这样才能清楚在出现问题的时候是哪个地方造成的,并且可以自行排查和解决,如不可控,则意味着一旦出现问题,就得依赖第三方来排查,那这个时间就非常不可控了,这也是网站不采用商用软件的重要原因。

编写高质量软件是保障系统高可用性的重要一环(可控性也是编写高质量软件的基础),但软件几乎不可能做到0 bug,各网站在总结自己保障高可用的经验中提到了一些策略用于保障系统的高可用,这些策略主要包括:监控/报警、容错、自我保护、隔离、和降级,需要做到高可用的软件在交付时都应具备这些特性。 监控/报警是软件自身能够保障高可用的重要策略,就像是汽车的仪表盘一样,可以告诉你油还剩多少,速度是多少,胎压是否正常等重要信息,对于软件而言,同样需要让外部可以获取到其运行的状况,例如Google的软件都会提供一个html的页面供使用者或开发人员访问(用过Hadoop的人也会发现这个特征),在这个页面上可通过key/value的方式来获取系统的一些运行指标,对外RPC的系统Google会采集所有的正常请求、错误请求以及其消耗时间的分布状况(>0.05s的,>0.1s等),除了监控系统的运行状况外,也需要提供一些方式以便外部能简单判断系统运行是否正常,例如curl某页面等,对于不正常的现象要进行即时的报警,以尽可能做到在故障尚未影响到用户时进行解决。 软件会依赖很多外部的因素,例如机房、硬件、数据库、服务等,而所有依赖的部分都是有可能出现故障的(要坚信这点,互联网的特色是所有小概率事件都会发生),在设计软件时需要考虑当依赖方出问题时,如何能保障软件本身的可用性,因此一定要做一些容错的处理,例如对于机房故障,各网站通常都会租用或建设多机房来避免;又例如Google采用IDE硬盘来存储文件,不做Raid,于是采用了复制三份的策略来避免硬盘故障导致数据丢失。 软件通常会接受外部的输入,而有些时候输入条件的不符合预期可能会导致软件的故障,在我们的系统中曾经出现的一个故障案例:某系统对外提供了批量查询的功能,结果有一次客户端提交了一个查找10000个用户的批量查询,导致系统由于内存不够出现了故障,因此在设计软件时需要保障处理自己能力范围的请求,对于超出能力的请求可以考虑直接抛错,还有一种常见的是后端处理变慢导致雪崩效应的故障,这种在软件上通常会采用超时、限流等方式来避免,对于这些可能出现的故障在设计软件时都应考虑采取一些保护的措施来保护自身的可用性。 软件通常提供了多种功能,这些功能会有重要的和不重要的,如果由于不重要的功能异常导致重要的功能出现问题,显然是不合算的,因此在设计软件时需要充分的考虑异常的隔离,不互相影响,例如在Google的系统设计中会采用Prioritized Request等策略。 降级即为James Hamilton的那篇著名的《On Designing and Deploying Internet-Scale Services》论文中提到的Graceful Degradation,降级通常采用的方法是在故障将要出现或出现后,通过关闭系统的一些功能来降低故障产生的影响,例如网站上有些操作可能是特别耗资源的,而这些资源的消耗又可能会导致影响到核心功能,一旦出现影响时,就可以通过关闭这些功能保障核心功能的可用,降级通常用于临时的绕开故障,故障的原因则事后排查。

交付具备高可用特征的软件是开发人员的重要职责,而对于一个网站而言,软件不是一次性交付的,也不是好几年才升级一次的,而是频繁交付的,因此对软件本身的维护也是保障高可用的重要环节。 通常,系统的不可用是变更造成的,如何降低变更对系统可用性造成的影响,是各网站都关注的重点,Google在发布时通常采取“滚木移石”的方法、Facebook则通常采用Dark launch的方法,以降低变更带来的影响。 人工来操作系统的变更是故障产生的隐患,因此各网站基本都会推荐多种工具来实现系统变更的自动化,例如采用puppet来实现自动化的部署。 除了发布这个重要环节外,处理故障也是维护的重要工作,系统总是会有出现故障的时候的,出现故障时如何快速的处理来降低对可用性的影响也成为了网站一直关注的重点,前文已经说到可控性对解决故障的帮助,除了可控外,各网站也会研究一些其他的方法,Facebook就采用了FBAR来自动处理部分故障,这显然可以一定程度降低故障产生的影响。

性能 在前文中提到的可控性同样也是保证性能的重点,只有明确的知道调用的每个API,依赖的环境(包括软硬件)的细节原理,才能编写出高性能的软件。 从系统结构上来看,我们可以看到各大网站在发展到今天的时候,为了保障高性能都采用了类似的方法,首先是前端Web系统这块,都采用了可编译为机器码的方式,例如即使是Facebook采用php,其仍然研发了一个可自动转化为C++代码的产品来提升运行效率。 设计系统时应考虑将没有前后依赖的逻辑并行化处理,,或者将大的请求进行拆分,例如在Google上进行搜索,Google会进行分词,然后并行的进行索引的查询,从而提高响应速度。 基本上各大网站都极度依赖Cache,这原因很明显,内存的访问速度远快于磁盘,依赖Cache的场景中最需要做到的是数据一致性的合理保障,一个典型的场景是数据更新时保障Cache一致性的策略,Cache的更新和数据的更新如果要做成一个事务显然有不小的难度,此时网站常采用一个简单策略来保障,就是先失效Cache,再更新数据,等到下次系统去访问此数据时,才更新到内存。 除了Cache外,可以看到各大网站都采用了CDN,CDN可以让静态文件更加的靠近用户,以便用户快速获取,而除了让静态文件更靠近用户外,多IDC的建设除了提升可用性外,还可实现让动态数据更靠近用户,当然,这个在技术上的实现难度会比CDN高很多。 除了结构上的这几点外,技术创新是提升系统性能的重要方法,例如Google提高TCP的初始拥塞窗口值等,而要做到技术创新,显然可控性就是基础了。

成本 随着网站规模的不断扩大,系统的运行和维护成本将会成为公司中支出的重要部分,例如有数据表明腾讯每年的支出中,支付给运营商的费用是其中占比排第二的部分(2010年为208亿),因此网站规模越大,成本控制就越重要(潜台词是网站规模在不是很大的时候,也许支撑业务快速发展更重要),例如Google在设计系统时price/performance是重要的考量指标,有些网站也会采用x元/每千次page views来计算成本。 性能优化有些是需要增加成本的(例如cache、CDN),而有些性能优化是可以降低成本(例如Google对Index结构的优化)的,因此通常性能优化也是降低成本的一种方法,网站规模大了后的规模效应可以让有些性能优化带来的成本降低非常的明显。 硬件的不断升级,而软件系统层面上又更多的是靠cluster来支撑,因此通常很难完全消耗硬件资源,虚拟化就成为一种不错的降低成本的方法,虚拟化具备了很好的隔离机制,避免了应用的互相影响,因此落地的难度不大。 除了依靠虚拟化来降低成本的方法外,Google则采用了自行实现的一种Shared Environment的方法来降低成本,Shared Environment可根据不同类型的资源消耗,动态组合(例如分时)部署到同一台机器上,充分的发挥机器的资源。 在前文中也讲到,网站主要是靠可伸缩存活下来,随着规模的扩大,必然会有大量的机器, Google有上百万台的机器,Facebook有几十万台机器,在这么大规模的情况下,自行根据应用特征设计机器,会带来很大的成本下降,因此Google、Facebook都自行设计机器以及自行设计DataCenter,从PUE上就可以看到Google/Facebook自行设计DataCenter带来的成本降低是非常可观的。

以上四点挑战会由于网站业务的不同、人员知识结构的不同、做事风格的不同以及所处的阶段不同而采用不同的方法去解决,每个阶段都有自己适用的解决方案,例如Google在成立之初业务为搜索,相对而言搜索市场的竞争主要是技术,功能次之,而facebook/eBay等网站的竞争压力主要在业务功能上,因此在成立之初的时候必然会有不同的侧重点,所以也不用想着一开始就去把网站做成Google/Facebook等现在的结构,选择适合自己网站的就是好的,很多开发人员在加入规模较大的网站后,会觉得系统结构已经稳定了,没有发展的空间,但从上面各网站的发展历程来看,可以看出网站对技术的要求是不断在演变的,通过观察大网站的发展历程,对自己结合公司的业务背景、知识结构等来判断其下一步的发展,是会有很大的帮助的,并且也可以借此储备一些技术,以把握技术演变时的机会,获得更大的成长,如果是加入规模尚小的网站,技术储备做的好的话,就有机会亲身经历网站从小到大的演变了,因此都有机会,就看个人如何把握。 围绕这四个方向的发展,通常网站在发展到一定规模后会演变成类似如下的结构: 除了在可伸缩性、可用性、性能以及成本这四点的技术挑战外,网站还面临了其他很多方面的挑战,例如海量数据的分析和挖掘、网站安全、业务发展的灵活性支撑、人员增长后庞大的软件管理等等,因此构建一个支撑大访问量、长期发展、低成本运行的网站是需要有坚实的技术作为支撑的。

知名网站的技术发展历程 一个Java应用频繁抛异常导致cpu us诡异现象的案例

Leave a Reply

Cancel

Name (required)

Mail (required)

Website

CAPTCHA Image

Refresh Image

CAPTCHA Code /*


July 2013 M T W T F S S « Mar 1234567 891011121314 15161718192021 22232425262728 293031

Categories

Tags

btrace c1 c2 Deflater facebook gc gc tuning Grizzly HBase hotspot Inflater interpreter javac java code generation JavaOne javaone general technical session java代码执行 Java 并发 jit jvm memory management Native Memory Leak NoSQL oom oracle keynote pessimism policy references RPC serial gc SOA sun jdk sun jdk oom Web容量规划的艺术 yuanzhuo 书:分布式Java应用 书评 互联网技术 交流 内存管理 分布式Java应用 圆桌交流 容量规划 悲观策略 服务框架 硅谷公司

订阅

推荐书籍

My Book

© BlueDavy之技术blog 2013

Icons & Wordpress Theme by N.Design

firefox下如何实现window.event.clientX

Posted on

firefox下如何实现window.event.clientX

phphot

Show

发表于 @ 2008年03月25日 09:49:00

InfoQ 企业架构师应担任什么角色

Posted on

InfoQ 企业架构师应担任什么角色

关闭

现有用户:

Email:

密码:

新用户:

InfoQ

直接转至内容 时刻关注企业软件开发领域的变化与创新

En | 中文 | 日本語 | Br

新闻

企业架构师应担任什么角色

作者 Boris Lublinsky译者 侯伯薇发布于 2010年8月1日 上午4时8分 社区架构主题职业生涯 ,企业架构

分享 Share|

此次圆桌会议由Interarbor Solutions的首席分析师Dana Gardner主持,他首先做了开场致辞: 现在对企业架构师的需求看起来比以前更紧迫了,但是让企业架构师职业并不一定会提升它的可信度和可采纳程度,至少现在还不行。

参与此次圆桌会议的有:MIT信息系统研究中心的主管和首席研究科学家Jeanne Ross,Integritas Solutions的架构实践主管和开源组织的架构论坛主席Dave Hornford,以及开源组织的技能和能力小组的副主席Len Fehskens,他们对以下问题做出了更详细的叙述:

……IT从神秘的艺术向工程化科学的转变,企业架构师如何把握唯一机会,在业务架构和越来越高的业务敏捷性概念下起引导作用。

根据Fehsken的观点,企业架构师当前的职业状况,就像医生或者律师这些成熟的职业在两三百年前的状况一样。不仅没有任何认证,而且企业架构师的知识本身也因人而异:

我们当前的状态与律师类似,律师正是试图基于他们才拥有的秘密过程来兜售自己,那会让你在法官面前得到公平的对待。或者与医生类似,他们会说:“到我们的医院来吧,因为我们是唯一知道如何治疗这种特殊疾病的人。”

Ross和Hornford都认为当前的风险非常高。在数字化经济中,IT变得越来越重要,而合适的架构能够轻易地改变公司的地位。Ross还说:

架构师的角色就是要确保有一种先见之明…… 因此有大量的争论和预想,这已经成为架构师角色的一部分,高于技术并超出技术的范围……有一种艺术能够预想到组织的长期愿景……我们觉得这些都应该是革新……

Harnford对其进行了详细说明,他指出成功的架构应该专注于业务价值。根据他的观点,不同的组织可以用不同的方式来定义价值:

... 但是对其进行全面的支持是业务想要达到的目的吗?他们的愿景是什么?目标又是什么?从业者需要对以下问题非常明确:最终的状态会是什么样的,业务转化如何,以及公司的数字资产即IT资产如何推动公司的发展,从而他们可以将其目标转移到比他们的竞争者更有效的领域。

依他所见,成为成功的企业架构师的最基本的要求就是要具备领导能力,而不真正拥有所有知识:

如果你没有好的领导的技能,那么其他的能力都无关紧要了…… 如果你不从事领导工作并且不去承担领导的责任,那么永远不会成为架构师。当前职业的障碍之一就是很多架构师都没有做好承担领导职责风险的准备。

接下来的主题是架构师的价值所在,Fehskens 主张:

架构师的权威最终来自于他能够在总体上清晰表述架构价值的能力,这针对特定的架构,并且是在特定的情况下的…… 这恰恰是一位从技术人员转过来的架构师所存在的最大问题。他们会告诉你特性和功能如何,但是永远不会谈论到它能够带来的利益。

架构师面临的挑战包括:

……确保他们所架构的与目的相符…… 架构师用来处理架构方面问题的方法意味着敏捷和缩减成本不再是短期的关注点。这两点都是我们要创建架构的首要原因。

Ross警告说,引人注目的业务价值很少能够立即体现,但是通常会一直提升:

重要的是要一步一个脚印,向公司展示IT能够帮他们做什么,然后,随着时间的推移,就会发生质的飞跃。事实上,我猜很多公司会说:“看,我们比以前更敏捷了。” 这并不是因为他们说将会变得敏捷,而是因为他们说每天都会把事情做得更好一点儿。

Gardner对讨论做出总结,他说:

如果我们回到核心问题,也就是架构师应该实现什么,那么就可以理解什么是业务价值以及我们向客户交付的价值在何处?

企业架构师的角色会随着时间的改变而不断改变。二十年之前很少有人知道什么是架构师,而当前很多公司都认为企业架构师是他们的机能的基础所在。他们的职责也发生了戏剧性的变化,从技术职责(超级开发者)变为业务架构师和领导。这个职业一直在变化,暂时还不清楚最终会选择哪个方向。

查看英文原文:The Role of the Enterprise Architect

相关厂商内容

百度技术沙龙第4期(7月24日)演讲资料下载

Adobe Flash Builder 4简体中文正式版高速下载

Intel研发中心架构师张银奎:Design For Debug!

Excel项目主管:产品规划阶段的项目管理

惠普研发实验室创始人:跨国公司产品创新之路

相关赞助商

由InfoQ和MSUP战略合作举办的亚太软件研发团队管理年会珠海站(9.18-19),欲报从速

3 条回复

关注此讨论回复

架构师越来越像将军了发表人 翌翔 高 发表于 2010年8月1日 下午8时27分 Re: 架构师越来越像将军了发表人 Slivermedol Rin 发表于 2010年8月1日 下午9时25分

Re: 那IT行业中的军师又该是什么样的角色呢?发表人 翌翔 高 发表于 2010年8月1日 下午10时0分 按日期倒序排列

返回顶部

架构师越来越像将军了

2010年8月1日 下午8时27分 发表人 翌翔 高 之前觉得架构师很像军师,为了解决各种难题而筹谋划策。 看罢各位大师的总结,觉得架构师更像为了夺下城池(业务价值)而率兵打仗的大将军! 或许这个隐喻并不恰当,但我觉得这要比与建筑业相类比更加贴切、并富于激情!

回复

返回顶部

Re: 架构师越来越像将军了

2010年8月1日 下午9时25分 发表人 Slivermedol Rin 那IT行业中的军师又该是什么样的角色呢?

回复

返回顶部

Re: 那IT行业中的军师又该是什么样的角色呢?

2010年8月1日 下午10时0分 发表人 翌翔 高 蒜泥狠,刨根问底,呵呵 感觉 IT 行业中的军师有时是由架构师本人来兼职的(将军兼军师), 根据面对的情况不同而在两种角色间相互切换! 具体说来,军师的职责是出谋划策,正如文中 Fehskens 所说: 架构师的权威最终来自于他能够在总体上清晰表述架构价值的能力,这针对特定的架构,并且是在特定的情况下的…… 这恰恰是一位从技术人员转过来的架构师所存在的最大问题。他们会告诉你特性和功能如何,但是永远不会谈论到它能够带来的利益。 对于将军而言,这确实是个大问题,或许这本来就不是应该由将军来做的事,哪由谁来做呢? 答案是:军师。军师根据特定环境和个人经验,给出可行的解决方案。 最终由将军做出决断! 如 Fehskens 所说,“从技术人员转过来的架构师”所扮演的常常是军师的角色,而非称职的将军! 军师的职责是给出给出可行的解决方案,而将军必须对利益的得失做出明确的判断!

回复

InfoQ 7月89,346名独立访问用户

Search

特别专题

赞助商链接

MPDay珠海站 9月18日-9月19日 亚太软件研发团队 管理年会登陆珠海 五大专题名师荟萃 深入交流强调分享 欲报从速团购更惠

深度内容

Scala与Spring是个非常有前途的搭配。本文将通过具体的实例阐述如何将强大的Scala与久经考验、富有成效的Spring框架整合起来以发挥二者的优势。

在互联网公司推行SDL的一些经验和教训

本视频将从传统软件行业推行SDL(Security Development Lifecycle)和在互联网公司的区别入手,阐 述在互联网公司推行SDL所面临的挑战,分享我们在推行SDL过程中积累的一些经验教训。

SOA十诫

使用面向服务的架构(SOA)可 能会降低信息系统的成本。笔者探索了各种方法,通过遵守十大基本戒律以实现SOA最初期望达到的潜在价值。

传统开发和敏捷开发中的领导力差别显著。陈怡斐作为经历过传统开发和敏捷开发的管理实践者,告诉我们领导力在两种模式中转变,以及组织为了支持这个转变需要做好的准备。

书摘和采访:Deploying HTML5

Deploying HTML5一书的作者Aditya Yada曾是ThoughtWorks的高级构架师,如今是一家咨询公司的CTO。在这本书中,他详细介绍了HTML 5的标准组件,解释了各主流浏览器实现这些组件的方式,并通过示例代码讲解了各组件的用法。

本文主要介绍了如何基于Visual Studio 2010进行敏捷Scrum模式开发,包括基于VS 2010进行Scrum团队组织,对需求记录和跟踪的支持,对Scrum流程中重要事件的支持,以及VS 2010对产品质量的保证等。

Spring MVC与JAX-RS比较与分析

近日,来自SpringSource的Rossen Stoyanchev对Spring 3中的Spring MVC REST特性与JAX-RS进行了一番比较。

互联网公司大量web业务的发展带来了新的挑战与防护,传统的针对单一服务单一应用的安全防护已经无法满足安全需求,本演讲将以黑客的角度来描述如何应对这一挑战的一些思路,以及百度在这一思路下所做的一些应用实践。

联系我们 反馈 feedback@infoq.com Bugs bugs@infoq.com 广告 sales@cn.infoq.com 编辑 editors@cn.infoq.com Twitter http://twitter.com/infoqchina InfoQ讨论组 http://groups.google.com/group/infoqchina

InfoQ.com 及其所有内容,版权所有© 2006-2010 C4Media Inc. InfoQ.com 服务器由 Contegix 提供,我们最信赖的 ISP 合作伙伴。 隐私政策

MemcacheDB

Posted on

MemcacheDB, Tokyo Tyrant, Redis performance test – Tim[后端技术]

Tim[后端技术]

Tim's blog, 关于后端架构、互联网技术、分布式、大型网络应用、NoSQL、技术感悟等

Home | About | English version | 留言(Guestbook) | 订阅RSS Add to Google

Tuesday, Aug 11th, 2009 by Tim | Tags: English, memcachedb, redis, tokyo cabinet, tokyo tyrant

I had tested the following key-value store for set() and get()

1. Test environment

1.1 Hardware/OS

2 Linux boxes in a LAN, 1 server and 1 test client Linux Centos 5.2 64bit Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (L2 cache: 6M), Quad-Core /* 2 8G memory SCSI disk (standalone disk, no other access)

1.2 Software version

db-4.7.25.tar.gz libevent-1.4.11-stable.tar.gz memcached-1.2.8.tar.gz memcachedb-1.2.1-beta.tar.gz redis-0.900_2.tar.gz tokyocabinet-1.4.9.tar.gz tokyotyrant-1.1.9.tar.gz

1.3 Configuration

Memcachedb startup parameter Test 100 bytes ./memcachedb -H /data5/kvtest/bdb/data -d -p 11212 -m 2048 -N -L 8192 (Update: As mentioned by Steve, the 100-byte-test missed the -N paramter, so I added it and updated the data) Test 20k bytes ./memcachedb -H /data5/kvtest/mcdb/data -d -p 11212 -b 21000 -N -m 2048

Tokyo Tyrant (Tokyo Cabinet) configuration Use default Tokyo Tyrant sbin/ttservctl use .tch database, hashtable database

ulimsiz=”256m” sid=1 dbname=”$basedir/casket.tch/#bnum=50000000″ /# default 1M is not enough! maxcon=”65536″ retval=0

Redis configuration timeout 300 save 900 1 save 300 10 save 60 10000 /# no maxmemory settings

1.4 Test client

Client in Java, JDK1.6.0, 16 threads Use Memcached client java_memcached-release_2.0.1.jar JRedis client for Redis test, another JDBC-Redis has poor performance.

2. Small data size test result

Test 1, 1-5,000,000 as key, 100 bytes string value, do set, then get test, all get test has result. Request per second(mean)key-value-performance-1(Update)") Store Write Read Memcached 55,989 50,974 Memcachedb 25,583 35,260 Tokyo Tyrant 42,988 46,238 Redis 85,765 71,708

Server Load Average

Store Write Read Memcached 1.80, 1.53, 0.87 1.17, 1.16, 0.83 MemcacheDB 1.44, 0.93, 0.64 4.35, 1.94, 1.05 Tokyo Tyrant 3.70, 1.71, 1.14 2.98, 1.81, 1.26 Redis 1.06, 0.32, 0.18 1.56, 1.00, 0.54

3. Larger data size test result

Test 2, 1-500,000 as key, 20k bytes string value, do set, then get test, all get test has result. Request per second(mean) (Aug 13 Update: fixed a bug on get() that read non-exist key) key-value-performance-2(update)") Store Write Read Memcachedb 357 327 Tokyo Tyrant 3,501 257 Redis 1,542 957

4. Some notes about the test

When test Redis server, the memory goes up steadily, consumed all 8G and then use swap(and write speed slow down), after all memory and swap space is used, the client will get exceptions. So use Redis in a productive environment should limit to a small data size. It is another cache solution rather than a persistent storage. So compare Redis together with MemcacheDB/TC may not fair because Redis actually does not save data to disk during the test.

Tokyo cabinet and memcachedb are very stable during heavy load, use very little memory in set test and less than physical memory in get test.

MemcacheDB peformance is poor for write large data size(20k).

The call response time was not monitored in this test.

101 Comments »

  1. Leechael says:

Aug 12th 2009 at 04:47

这次的测试结果显然更新了,虽然还是不敌,不过这次 TT/TC write 的性能显然提高了。 :D

  1. Brendan O'Connor says:

Aug 12th 2009 at 11:32

very interesting, thanks!

  1. Jon Hancock says:

Aug 13th 2009 at 00:46

good info. One thing missing in these types of comparisons is a baseline against an RDB. Adding postgres 8.4 to this comparison might help.

  1. vicaya says:

Aug 13th 2009 at 03:28

You should really test memcached 1.4.0, which actually can use multi-cores.

  1. Asaf says:

Aug 13th 2009 at 03:51

Thanks for the info, Can you please detail the ratio of read / write operations and the order of the operations?

did you first write all the data than read all the data or was it intermittent?

  1. Tim says:

Aug 13th 2009 at 14:39

@asaf I do read test after finish all writes.

Write test: key: 1-5,000,000 value: 100-byte-string

After write all, then do read test client.get(random(5,000,000));

  1. Joshua Zhu says:

Aug 13th 2009 at 16:51

This benchmark is very helpful to me in evaluating those K/V stores. Thanks a lot.

  1. Guo Du says:

Aug 13th 2009 at 19:31

Very interesting result. Any significant cpu usage difference between those stores?

  1. Joubin says:

Aug 14th 2009 at 10:08

Hi Tim,

Thanks for the test! Just curious:

1) Try changing the tcp buffer sizes in class org.jredis.ri.alphazero.connection.ConnectionBase$DefaultConnectionBase. On my mac, the default values are always fairly quite large so perhaps this is something that was missed:

change the tcp rcv and snd buffer size values:

public static final class DefaultConnectionSpec implements ConnectionSpec {

/// // private static final int DEFAULT_RCV_BUFF_SIZE = 1024 / 48; // << increased /// // private static final int DEFAULT_SND_BUFF_SIZE = 1024 / 48; // << increased

2) May also try changing the tcp socket prefs (same inner class):

Try this:

public static final class DefaultConnectionSpec implements ConnectionSpec { …

@Override public Integer getSocketProperty(SocketProperty property) { int value = 0; switch (property){ case SO_PREF_BANDWIDTH: value = 0; // changed break; case SO_PREF_CONN_TIME: value = 2; break; case SO_PREF_LATENCY: value = 1; // changed break; case SO_RCVBUF: value = DEFAULT_RCV_BUFF_SIZE; break; case SO_SNDBUF: value = DEFAULT_SND_BUFF_SIZE; break; case SO_TIMEOUT: value = DEFAULT_READ_TIMEOUT_MSEC; break; } return value; } … }

I assume you’ve downloaded the full distribution from github. “mvn install” to build and run the test again. Curious to see if it makes any diffs. That fails we’ll try switching to buffered io streams.

/R

  1. Gabriel says:

Aug 15th 2009 at 02:30

Can you post the actual model/# for the Xeon CPU along with operating frequency?

  1. Tim says:

Aug 17th 2009 at 16:45

@Joubin I’ve changed DEFAULT_RCV_BUFF_SIZE/DEFAULT_SND_BUFF_SIZE from 48k to 256k, both for small data size and larger data size, but there is not significant improvement. The bottleneck here may not on the client side.

@Gabriel added.

  1. mongofan says:

Aug 19th 2009 at 07:47

hi Tim very nice!

can you add mongodb to the benchmark? I would love to see how it performs against redis

  1. Joubin says:

Aug 23rd 2009 at 22:04

Tim,

Thanks. That confirms my owns tests that stressed on just one key to isolate the client overhead.

A cursory look at the TT’s Java client seems to indicate that payloads are gzip’d (which JRedis does not, given that the baseline assumption is that you may be using a variety of clients for your db, in which case client specific optimizations are not viable unless the compression algorithm is shared by all client types.)

I’ll update when I have something to add here, but safe assumption here is that compressing the 20K payload has a significant positive impact on the performance of the TT setup.

  1. arden says:

Sep 3rd 2009 at 11:44

redis有没有象memcached这样的过期时间设置?

  1. Jonathan says:

Sep 11th 2009 at 04:37

I assume this tests write once?

You may see something interesting from Tokyo Tyrant if you test modification in random order. Write performance should drop to match read performance.

  1. Henry says:

Oct 3rd 2009 at 06:10

Thanks for the Test, we will test Redis in one of the next Projects

  1. Gregory Burd says:

Nov 19th 2009 at 03:12

To match Redis’s durability (“D” in ACID) using Berkeley DB simply set the DB_TXN flags to DB_TXN_NOSYNC. A transaction will be consider “durable” when the data is flushed from the log-buffers in-memory to the operating system’s filesystem buffers rather than waiting for the disk to actually write the data (which is much slower). There are many other configuration parameters that can be tuned, you don’t list them in your description so I can’t say if they were optimal or not (really, “auto-tuning” a database is something that BDB should do for you, but we’re not there yet). If these tests run entirely in cache (can load the entire dataset into memory) then this isn’t a realistic scenario, increase the dataset until the data is 10x the cache size. Also, as someone mentioned you may want to test under a highly concurrent, and highly contentious workload as that will push the locking systems and create very different results. Finally, update to Berkeley DB 4.8. In 4.8 we’ve dramatically improved our locking subsystem for modern multi-core CPU architectures.

Benchmarks are always tricky. :-) Apples-to-apples tests are rare because they are hard to design and harder to run. There is almost always some degree of bias or some overlooked element. It’s unavoidable. That said, benchmarks do serve a purpose so thank you for doing the tests. We hope that you do more. We’re always looking for ways to improve performance.

-greg

Berkeley DB Product Manager, Oracle Corp

  1. Tim says:

Nov 20th 2009 at 11:16

Greg, already enable DB_TXN_NOSYNC by add -N to memcachedb in this test. Will evaluated bdb 4.8

  1. Tim says:

Nov 25th 2009 at 09:47

Greg, tested bdb 4.8, there is significant improvent. Great! but after I compare with TC(tokyocabinet-1.4.39.tar.gz) and TT(tokyotyrant-1.1.37.tar.gz) new version, they also had improvement, so the result doesn’t changed much.

FYI, I’ve tested read/write 100 byte with 50 threads, the request per second result are, Tokyo Tyrant(Tokyo Cabinet) Write 54,189, Read 73,384 Memcachedb(Berkekey DB 4.8) Write 32,985 Read 59,178 Memcached Write 103,242, Read 106,102

Because the new test donen’t change the situation, the test in blog post still make sense.

  1. eric says:

Jan 6th 2010 at 13:45

感觉还是不错。

  1. focusheart says:

Feb 26th 2010 at 10:25

Redis应用在一个多层的存储结构中用来处理经常发生变化的数据部分很合适,存储结构的层次不同,适用不同的解决方案。

  1. faryang says:

Jul 2nd 2010 at 00:15

对我来说,REDIS是亮点,相见恨晚啊:)

  1. jtong11 says:

Mar 17th 2011 at 16:36

事实上,对于500万的小数据量而言,所有写入数据都有可能被文件系统buffer住,这时再进行查询操作,显然都是直接命中。所以真正有效的测试应该是写入超过内存2倍以上的数据,然后查询最先写入的那些数据。

  1. Louis says:

Mar 23rd 2012 at 17:20

I am a newer for Redis.Can I just ask a primary question?How did you get the value of Request per second?

  1. hunter says:

Oct 11th 2012 at 20:42

我们测试data > 100k时,性能会急剧下降(100次/s),不知道是不是我们的测试配置有问题,你能否帮忙测试一下?

RSS feed for comments on this post, TrackBack URI Cancel Reply

Leave a Comment

Name (required)

E-mail (required, never displayed)

URI

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution 3.0 License

firefox中的ajax同步传输

Posted on

firefox中的ajax同步传输

谌俊

firefox中的ajax同步传输

\

\

  • 谌俊 发表于 2009-9-7 15:59:37