17:01 Content Delivery Networks (CDN) – a comprehensive list of providers » High Scalability - Building bigger, faster, more reliable websites.

We build web applications…and there are plenty of them around. Now, if we hit the jackpot and our application becomes very popular, traffic goes up, and our servers are brought down by the hordes of people coming to our website. What do we do in that situation?

Of course, I am not talking here about the kind of traffic Digg, Yahoo Buzz or other social media sites can bring to a website, which is temporary overnight traffic, or a website which uses cloud computing like Amazon EC2 service, MediaTemple Grid Service or Mosso Hosting Cloud service.

I am talking about traffic that consistently increases over time as the service achieves success. Google.com, Yahoo.com, Myspace.com, Facebook.com, Plentyoffish.com, Linkedin.com, Youtube.com and others are examples of services which have constant high traffic.

Knowing that users want speed from their applications, these services will always use a Content Delivery Network (CDN) to deliver that speed.

What is a Content Delivery Network?

A Content Delivery Network (CDN) is a collection of web servers distributed across multiple locations to deliver content more efficiently to users. The server selected for delivering content to a specific user is typically based on a measure of network proximity. For example, the server with the fewest network hops or the server with the quickest response time is chosen. This will help scaling a web application by taking a part of the load from the service servers.

Read the entire article about Content Delivery Networks (CDN) list of providers at MyTestBox.com - web software reviews, news, tips & tricks.

13:44 本地在线媒体更具广告优势[OPA报告] » laolu's blog: Blog

2008年8月19日,美国在线出版商协会(OPA - Online Publishers Association)发布研究报告,名为“本地在线媒体:从广告到行动(Local Online Media: From Advertising to Action)”。报告有PDF免费下载

MarketingCharts有报道和图片
  • 报告调查了从互联网上的城市指南、分类信息、杂志、报纸、门户、电视网站、用户评论网站或黄页获得本地信息的消费者。
  • 本地媒体网站的用户从广告到行动的比例最高。较之其他本地内容网站的访问者,在三类本地媒体网站——报纸、电视台和杂志的消费者,看到一则本地广告后更倾向于采取行动(购买、研究、去商店等),从广告到行动的比例位三甲,报纸、电视台、杂志的网站分别为46%、44%、42%。

  • 本地媒体网站的用户是更有含金量的广告目标。本地的杂志、报纸和电视台的网站访问者,过去一年在线消费超过$500的比例分别为48%、40%和39%。而门户访问者、所有在线用户达到这一消费额的比例为37%、34%。
  • 信任是本地媒体网站广告取得成功的有一个重要因素。相信本地报纸、电视台网站广告的访问者比例最高,分别为56%、55%,门户广告的信任度排第三,为53%。

  • 还有,至少每周访问的用户,对本地媒体网站的满意度更高,本地电视台、报纸网站的用户满意度最高,分别为79%、77%;而门户网站经常用户的满意度为65%。
  • 本地在线内容网站的共同特征,是有能力吸引影响者(influencers)的高度关注。如果按GfK Roper报告所称,10%的消费者会被认作“影响者(Influentials)”,那么,29%的本地在线内容网站用户说,他们是推荐本地餐馆酒吧的第一人,26%的人说是本地购物推荐的第一人,23%说是本地娱乐、消费类电子产品推荐的第一人。
OPA总裁Pam Horan表示:“凭借强势品牌和受信任的氛围,本地媒体网站能为本地广告主带来实在的结果。”

/*

  • 中国的报纸们喜欢把内容卖给新浪们,心里又想着打败新浪们,实际上又被新浪们慢慢打败。新浪们“早已经是主流媒体”,报纸们当然还是主流媒体,有边缘媒体吗?央视也大卖视频内容,不怕步报纸的后尘?地方报纸、地方电视台呢?
  • 中国各地都有类似热线、信息港等的地方门户,这就是本地媒体网站?谁在运营,还有谁能运营所谓的本地媒体网站?
  • 中国的本地在线广告有市场吗?

*/

13:31 TechCrunch 50创业盛会的12个创业板块和Y Combinator鼓励的30个创业方向 » 大学小容>善用网络,助益成长!

今天是TechCrunch 50的第二天。没有仔细全程观看视频直播,只在早上看了两个项目的演示,评委之一传奇创业家马克·库班(Mark Cuban)甚是凶猛,看来创业者在秀项目的时候事向要做足了功夫。有人在Twitter里报道说,有2619人登录USTREAM收看TechCrunch 50,这个数字不包括未登录的用户。

在小容看来,今天最令人振奋的项目应该是Swype

一句话评论:一种全新的屏幕文本输入法。Swype的创始人是T9输入法的创始人,现在带来革新一代的技术。


TechCrunch 50评选出50个项目,分为12个主题板块,分类不是非常严谨,有些项目和所属板块也不是非常贴切。不过,好在这是个会议,不是像CrunchBase那样的结构化数据库。这些主题倒是可以给我们一些借鉴。小容简单罗列在下面,供大家参考。

Session 1: Youth and Culture (潮流文化)

Session 2: Memes & News (媒母与新闻)

Session 3: Enterprise(企业级应用)

Session 4: Advertising & Commerce Monetization (广告与商务)

Session 5: Collaboration (协作)

Session 6: Finance & Statistics (财务与统计)

Session 7: Mobile (移动通讯应用)

Session 8: Language & Communication Tools (语言与沟通工具)

Session 9: Rich Media (富媒体)

Session 10: Games (游戏)

Session 11: Vertical Social Networking (垂直社交网络)

Session 12: Research & Recommendations (研究与推荐)

新兴的创业公司孵化器Y Combinator的创始人保罗·格雷厄姆(Paul Graham)前些时候写了一篇文章(英文原文中文搜索),阐述了他认为值得投资的30个创业方向。小容也罗列在此,和上面的12个创业主题可以对照着看(关于Y Combinator和Paul Graham的背景请看本文最后的相关链接)。

Startup Ideas We’d Like to Fund

by Paul Graham

1. A cure for the disease of which the RIAA is a symptom(解决版权纠纷的方法)
2. Simplified browsing(简化的浏览)
3. New news (新新闻)
4. Outsourced IT (IT 外包)
5. Enterprise software 2.0 (企业级软件2.0)
6. More variants of CRM(更多样化的顾客关系管理系统)
7. Something your company needs that doesn’t exist (己所欲也,无所求也)
8. Dating (在线交友)
9. Photo/video sharing services (照片/视频分享服务)
10. Auctions(拍卖网站)
11. Web Office apps(Web办公套件)
12. Fix advertising (合理化广告模式)
13. Online learning (在线学习)
14. Tools for measurement (测量工具)
15. Off the shelf security (现场电子安防)
16. A form of search that depends on design (提升用户体验设计的搜索引擎)
17. New payment methods (创新的支付模式)
18. The WebOS (网络操作系统)
19. Application and/or data hosting (应用/数据存储)
20. Shopping guides (购物指南)
21. Finance software for individuals and small businesses (低端财务软件)
22. A web-based Excel/database hybrid (基于Web的excel/数据库软件)
23. More open alternatives to Wikipedia (以更开放的方式取代维基百科的挑战者)
24. A buffer against bad customer service (改善糟糕的客户服务体验)
25. A Craigslist competitor (与在线分类广告网站Craigslist竞争)
26. Better video chat (更好的视频聊天工具)
27. Hardware/software hybrids (软件和硬件的混合应用)
28. Fixing email overload (解决电子邮件信息过载问题)
29. Easy site builders for specific markets (为特定市场提供快速建站工具)
30. Startups for startups (为创业公司服务的创业公司)

回顾一下这个清单,再看看TechCrunch 50和最近的一些新产品,是不是感觉地球转得太快了,几个月前讲的事情,现在有许多团队已经做出了产品。

如果你关注网络创业的新方向,那么,最后一定不要忘记这条“旧”新闻:

Flickr的联合创始人Caterina Fake在她的blog里宣布自己刚刚加入纽约的新创公司hunch.com,担任首席产品师(Chief Product Officer),同时位列董事会。hunch.com尚未发布,Caterina Fake也没有透露hunch.com是个怎么样的网站,只说是一个面向大众的应用。

让我们拭目以待吧,看看hunch.com会不会带给我们超过Flickr的惊喜。

此外,对于Caterina Fake来说,另外一个好消息是,她刚刚加入创作共用(Creative Commons)的全球董事会成员,Flickr.com在推广创作共用(Creative Commons)上的努力和成就世人有目共睹

相关链接:

保罗·格雷厄姆(Paul Graham)是硅谷著名的程序员之一,在1995年他和Robert Morris开发了第一个基于Web的应用程序Viaweb,该项目在1998年被雅虎(Yahoo)收购。在2002年,他设计了一种垃圾邮件过滤器算法。他同时还是计算机程序语言Arc的设计者,写了多本关于程序语言以及创业方面的书籍。在2005年他和3位合伙人成立了Y Combinator创业投资基金公司,专注于早期阶段的种子投资。

1、Wiki上的保罗·格雷厄姆(Paul Graham)(英文

2、保罗·格雷厄姆(Paul Graham)的个人主页(英文

3、Y Combinator创业投资基金公司(英文

4、《Kiko启示录之时机与火候》背景资料及超链接

5、《Kiko启示录之时机与火候》小容早些时候写的文章,Y Combinator是Kiko的投资者。

Slashdot的游戏规则雄杰 » 车东 在 Google 阅读器中共享的项目

     游戏规则,小至一个团队,一个公司,一个游戏,一个用户产品,大至一个社区,一个城邦,一个国家,规则(制度)永远都是其中最重要的。因为常说人生如戏嘛,我更愿意把这种制度的东西称之为游戏规则。因为社会游戏规则的变革,导致我们看到社会的变革。我们从原始社会到奴隶社会到封建社会到社会主义社会(资本主义),有两种东西在演变,一是生产力的演变,一是生产力基础之上的生产关系的演变。

     生产力决定生产关系,经济基础决定上层建筑。这是理解一个社会中的规则的核心出发点。

     对于一个博客产品来讲,这里的生产力是怎么样的呢?生产关系如何呢?经济基础如何呢?上层建筑如何呢?要理解这些问题,我们可以向现实社会学习,以一个持续发展的眼光来仔细的审查下博客社区发展的来龙去脉。

     博客社区里有游戏规则吗?我想是没有的,或者说我们有的那些游戏规则很不公平、很不公开、很不公正,很不可持续发展,很简单,很粗暴,很不合理。由此导致,只有在生产关系(游戏规则)之上才能稳固发展的文化、只有依托与某种制度和措施才能壮大的文化无从流行起来,零星自发形成的一些文化,由于没有一个游戏规则的存在,这种文化无法稳固,无法多样化,无法持续发展。

     在游戏规则方面,国外有很多优秀的站点,Youtube,Google的Pagerank,国内百度贴吧、知道都是其中的佼佼者。各种网络游戏更是擅长此道,另外还有三个网站的游戏规则也被众多人研究较多并且与博客社区与更多相通之处,分别是:Slashsot的管理驱动新闻模式/Digg用户驱动新闻模式/IMDB的打分规则。让我们一一来看看他们是怎么做的,这篇文章只说Slashdot的。(以下资料来自网络)

  Slashdot.org是一个美国站点,在Digg诞生之前就已经存在,以极高的用户参与度著称。在一篇文档中,该站点的创始人描述了站点评论管理制度的发展历史。让我们来看看他是怎么说的:

  加入评价机制之前

  最初Slashdot是个小站点。每天只有几十条帖子,情况良好。我们是无名之辈,无需去做评价。后来不一样了。每天都在增加更多用户,评论数量也在增加。这时,很多用户开始滥用系统。作者只能删除讨厌的评论。用户日渐增长,我们发现很难维持内容质量——军力实在太悬殊了。

  手工挑选

  所以,我挑选一些人来帮忙。25人左右,很少。他们被授权给评论加分或减分。这些“勇敢灵魂”的基本功用是清除垃圾、“首发”和硝烟诱饵(煽风点火、引发激烈论战的言论)。还要找出精华的内容,放到外面

  系统工作正常,但Slashdot持续成长,显然25个人已经无法处理每天数千的帖子。需要更多人。

  400个幸运儿

  然后我们只能继续找人。按照之前25人的方式,又找了400人。这400人发表过高质量评论。很快其中几十人就因为滥用权利而被撤职,但多数人安定下来。

  这时,我开始试验如何限制评分者滥用权力。25个人很容易监控,但如何监控400人就是大问题了。我知道有一天自己会控制得更少,因为我打算让更多人来管理站点。评分者能用的分数从几百下降到几十。

  从这段描述中,我们仿佛看到了一个国家的政治史。最初是独裁政治(站点运营者自己管理),后来过渡到郡县制(多个版主管理)。我们也看到,多达400人的版主队伍,并没有起到预想中的良好效果。原因何在?

  归根结底,论坛需要一套评价体系来管理。评价体系包括:对帖子的评价,对用户的评价,对评价的评价。这套评价体系应该是基于“用户自治”,但又不可依赖固定的一个/一些用户。借鉴陪审团制度,Slashdot创造了这样的评价体系。到目前为止,它仍然是最为有效、最为先进的评价体系。设想一下,一篇帖子可能有上千回帖,而且用户在缺省状态下只会看到质量较高的回帖。类似“up”、“顶”、“gz”这样的回帖,或者更为恶劣的回帖,甚至无需由所谓“版主”去删除——它们依然存在,但却基本没有人会看得到。要做到这一点,原理很简单:对每篇帖子进行打分,用户可以设定自己只看几分以上的帖子,于是分数较低的帖子自然就消失在人们的视野之外。

  说起来简单,但“打分”本身如果没有得到有效利用和监督,就会出现滥用权力等种种不良现象。另一个被广泛认同的说法是:过度民主比不民主还要糟糕。谁打分?怎么打分?这是个问题。还是让我们来看看Slashdot.org的做法吧。(以下内容摘自Slashdot.org在线FAQ文档。)

-----------------------------------------

  我的评论会被删除吗?

  不会。我们相信Slashdot中的讨论如同在真实世界中一样——你不能改变自己曾经说过的话,只能试图去进一步阐释或澄清。也就是说,你不能删除自己贴上去的评论,只能回复并试图说清楚事情。

  简而言之,点击“提交”之前,应再三考虑,后悔药是没有的。

  看起来评论质量在下降,你们有办法解决吗?

  我们拥有一个评价体系。

  Slashdot用户数量与日俱增带来的负面影响就是捣乱者也增加了。只要有一小撮人捣乱,就会制造大量噪音。评价体系的一个基本目的就是把这些噪音平息到最小音量(详情见后)。

  评分看起来很严格。必须这样做吗?

  答:对。如你所见,Slashdot上有大量评论,每天数千条,每个月数万条。在任一时刻,数据库需要处理超过50,000条评论。一篇文章可能有上千条回复——面对现实:并非所有评论都是高质量的。实际上,有些评论很糟糕,另外一些则是精华。

    评价体系旨在从信息流中筛选精华与垃圾。它尽可能地请网站读者负此重任。

  目标是每位读者应能够按照自己喜欢的级别阅读Slashdot。没耐心的可以只读原文;有些人只想读得分最高的评论;有些人不想看到匿名评论;还有些人希望不漏过一个字,从“首发”评论一直到垃圾评论。我们创造的系统能实现这些愿望。至少,它努力去实现......

  评价体系的目标:

  •提倡高质量内容,抑制低质量内容。

  •让Slashdot满足尽可能多人的“可读性”要求。

  •无需耗费单个评分者过多时间。

  •不允许单个评分者成为“恐怖大王”。

  总体上,我们认为评价体系工作得很好,但常有人不这么认为。不同意见源自多个方面,有人看到评分互相抵触,有人看到某条评论得分完全错误......还有捣乱者搞出一条跑题评论,以为系统被攻破了。

  当然系统是有漏洞!它的运作原理是让各色各样的人志愿花时间来作贡献。有些人自私而具破坏性,另外一些人工作努力有效。我认为全部工作加起来,是绝好的。

  把阅读阈值设定为3,注意看评论质量。你阅读的不再是毫无管理的讨论,而是来自许多聪明人的有益观点。我确实为此着迷。

  谁是评分者?

  这也许是过程中最困难的一个环节:谁会被允许评分。一方面,很多人说“每个人”,但我并没选择这种方式,因为隐患极大。我设计了一些简单的规则,判断谁适合评分。

  •登录用户

  如果系统不保持跟踪,就不能运作起来,所以你必须登录。很遗憾你处于被怀疑的局面,但系统需要某种程度的责任制。

  •活跃读者

  脚本追踪每个登录用户的阅读行为。系统挑选达到一定平均阅读量的读者。首页不计入阅读量。不断刷新页面的不会被挑选,偶尔访问的也不会被挑选。

  •长期读者

  系统拒绝选取最新的几千名读者,防止利用马甲获得评分权,更重要的是新手必须先花上几个月时间成为社区一员和了解系统,方有机会得到评分权。

  •自愿参与

  如果不想参与评分,请把自己的状态设置为Unwilling。

  •参与度高的读者。

  系统追踪你的“因果值(karma)”。如果karma评定为Positive,Good或Excellent,意味着你的评论好多于坏,适合做评分人员。这能清除垃圾账号。

  结果就是得到一个装满适合的评分人员的“池子”。大约30分钟一次,系统检查已发评论的数量,向池中用户发放相应适当数量的“令牌”。

  当某个用户得到一定数量的“令牌”时,就成为评分者。要得到评分权,你需要持续保持良好记录。系统运作机制是保证每个人都有机会,每个人都不能滥用权利,以及只有积极用户才能成为评分者。

  评价体制如何工作?

  评分者得到评分权后,会拥有一定数量的可用点数。每次打分耗费一个点。当点数用完后,评分权力自动失去。

  在评分时,只需要在每条评论旁边的下拉列表中做选择(选择项包括Flamebait——“硝烟诱饵”或Informative——“言之有物”这样的直观评价)。贬义词降低评论得分,褒义词则增加评论得分(均为一个点)。所有评论的得分均在-1到5之间。登录用户的评论初始得分为1,匿名用户的评论初始得分为0。

  评分者不能对自己参与的讨论打分。目的是为了防止滥用权力,这种做法有争议,但我坚持如此。

  未被使用的评分点数三天后失效。你失去评分权,回到“池”中,等待某天再次被选中。

  更多地把注意力放在选择好的内容,而非打击差的内容上。评分的真实目的是筛沙出金,让人们阅读。不要推荐个人化内容,不要被自己的观点所左右。努力做到公正无私。不同意其观点,不是给评论打低分的理由;同样,同意其观点,也不是给评论打高分的理由。

  编辑参与评分吗?

  编辑拥有无限的评分点,而且也会去使用它们。

  来自编辑的评分大概占总评分量的3%。根据MetaModeration统计,编辑评分公证性不低于非编辑评分,而且更高。原始数据是95.1%的非编辑正面评分是公正的,94.7%的编辑正面评分是公正的;79.1%的非编辑负面评分是公正的,83.6%的编辑负面评分是公正的。

  什么是阅读阈值?

  所谓“阈值”,即对于某个具体用户,评论在被显示出来需要达到的评分等级。评论得分从-1到5不等,所以也可以在此范围内设置阈值。例如,如果你设定阈值为2,则只有得分为2或2以上的评论会被显示。设定阈值为-1,所有评论都会显示。0是几乎所有评论,1过滤掉大多数匿名评论,如此等等。阈值设定越高,能看到的评论越少,但(理论上)得到的内容质量会更高。

  什么是“因果值(karma)”?

  因果值(Karma)代表你的评论的得分记录。Karma被设定为以下等级:Terrible,Bad,Neutral,Positive,Good和Excellent。评论被打高分,则karma值上升,反之亦然。

  其他因素也被计入karma。上传一篇文章并获得通过可以获得karma。同样,作为打分者的表现也会导致karma值的变化。这个体制鼓励人们成为好的评分者,防止“坏人”进入评分者队列。

  Karma可以无限积累吗?

  不能。Excellent是最高的Karma值,这样可以防止因为积攒了过高的分数而导致不会被评分所影响。Karma限制对每个账号都起作用。

  我继续努力,但无法得到更多Karma,这不公平。

  Karma被用来把危险用户从“池”中清走,同时也是给贡献度高的用户的一种奖励。Karma不是IQ,不是××(不雅未译),不是个人价值体现,也不是电子游戏得分。它并不判断你是否是Slashdot的合格读者。它不能治愈癌症,也不会在2012年当骷髅军反攻地球时在飞往火星的秘密飞船上为你争取一席之地。当用户发言、评分、和对评分本身进行评价时,karma值都会变动。不要被它所困扰,它不过是数据库中的一个数字罢了。

  Karma的好处是什么?

  Karma被用来决定谁有评分权。极度恶劣的karma值通常表示该用户在讨论区中一向都在张贴垃圾。

  其次,拥有良好karma值的用户,会被授予额外的奖励,有时这种奖励能增加你的Karma评级。登录用户发表评论初始值一般是1,但如果你karma值比较高,则初始值可能是2。基本上这是对表现良好的参与者的奖励,也是对“坏家伙”的惩罚。低karma登录用户发表评论,初始值可能不是1。特别差的用户发评论初始值会变成-1。

  Karma:最低是什么?

  最低的karma评分是“Terrible”。

  Karma值很低时,评论初始得分会是-1,评分者们鲜有可能看到你的言论,所以你很难再丢分。

  每次我使用+1奖励时,就会得低分,karma值降低!

  作为良好表现用户,你获得奖励:比别人更“大声”地说话。在行使权力的同时,你也要承担责任——有效地使用奖励。讲话越大声,越有可能被打低分,除非你的言论让评分者们认为足够好。这就是评分体制的要点:不能让人积累karma值,然后胡说八道。

  为什么评分者只能得到5个评分点数,而不能对5篇文章的所有评论打分?

  好问题!评分者们常常抱怨可用点数太少,而需要打分的评论又那么多。如果一个好评分者能够对一篇文章的所有评论打分,绝对是个大进步。

  问题是,一个坏评分者可能滥用权力,在同样这5篇文章中肆意乱来。限制评分点数为5,每个评分者的破坏性也受到限制。我宁肯看到一百个未被打分的评论,也不愿意看到一百个被胡乱打分的评论。

  评分下拉框中的选项意思是什么?

  •Normal——缺省值。通常无需选择这个选项。

  •Offtopic(跑题)——评论和原文无关。

  •Flamebait(硝烟诱饵)——如果一条评论的全部目的就是挑起战火,它就是Flamebait。

  •Troll——Troll类似于Flamebait。Troll目的在于引起愤怒或迷惑的后续评论。一条Troll评论可能有意混淆黑白,让别的读者来作“纠正”。这种行为纯属浪费别人的时间。

  •Redundant(冗余)——Redundant不增加新信息,只是重复别人的观点。例如,一些用户从别处剪贴内容到某个讨论,就是Redundant。

  •Insightful(有见地)——有见地的帖子启人思维,给出新想法。

  •Interesting(有意思)。

  •Informative(言之有物)——添加新信息的评论。

  •Funny

  •Overrated(被高估)——由于某些原因,评论得分过高。

  •Underrated(被低估)——打分过低。

  好了,上面的文档已经足以让我们了解Slashdot评价体系的要点,重申一下,那就是:对帖子(内容)的评价,对用户的评价,以及对评价的评价。打分者来自评价较高的用户,打分结果既影响对帖子的评价、对作者的评价,也会影响对打分者本人的评价。通过这套评价体系,好的用户和好的内容被成功地筛选出来。

10:28 UCD大社区攻略 » UCDChina.com

UCD大社区上线整整40天了,通过大家的留言和书友会的反馈,回答几个大家比较关心的问题:

1 为什么要会有一个UCD大社区?
你可以理解成这是一个知识库:
当你正在为导航设计犯难的时候,可以查看导航设计的话题
当你在想登录和注册的流程和界面怎么设计的时候,来看看这里
当你在为网站设计“好友”关系的时候,不妨来这里看看网上的头脑风暴;
……
我们希望能通过话题的方式帮助每个设计师解决一些实际的问题,至少也能让你拓宽下思路。

如果你持续关注UCD大社区,我们会给你关于最前沿的热点话题和好的文章,如果你不想对着reader里面恐怖的1000+,但又不想错过关于行业的任何一篇好文章。你可以订阅这个feed或者直接访问我们的网站。

2 一进来不明白所以然,从哪里开始浏览?
如果你是个设计新手,建议从你感兴趣的话题开始,当你读完这些话题,将话题串起来,就是以用户为中心的设计流程。
如果你是个设计老鸟,你可以按导航上的类别阅读,同时你也可以按话题查看,相信旧文新读你也会有新的收获。
首页左侧更新是以话题为维度,如果你是个“时间控”,网站右侧的“最新信息”模块,是按照文章的收录时间排序(不包括“设计之外”和“业界信息”的文章),关注那里就好。
(高级攻略:点击文章旁边的望远镜,你可以查看文章快照)

3 大社区的内容相比原来的团队博客,会不会更“水”?
我们只是不一起在同一个博客上码字,我们有好的想法,你一样能看到团队作者的文章。
而且,每一篇被收录的文章,都是经过人工审核的。

4 为什么不能评论?
是的。
如果你对文章有想法,你可以到源地址去回复;
如果你对这个话题感兴趣,到你的博客写一篇文章,点网站右侧的“我来发布信息”提交给我们,如果你的文章我们认为有价值,会收录到相关话题里去。

转载请注明出自UCDChina.com,谢谢。

相关文章

09:21 The performance effects of new patches » MySQL Performance Blog

We are going to show the effects of the new patches applied to Percona HighPerf release. As you see from the following graphs, there is significant difference to normal version when the data bigger than buffer pool (right graph shows CPU usage)

The workload emulates TPC-C and has a same characteristic to DBT-2 (it is not DBT-2, but custom scripts, we will publish them eventually). There are no delays between transactions (no thinking time, no keying time), it uses MySQL C API and the server side prepared statement.

The server has 8core CPU and RAID storage (RAID10 / 6 disks). The data population is along to the scale factor 40WH (:=~4GB). It is enough bigger than the data cache of the storage.

main common settings

innodb_buffer_pool_size = 2048M
innodb_thread_concurrency = 0
innodb_max_dirty_pages_pct = 70
innodb_flush_method = O_DIRECT

The next graphs show the frequency of IO, and you can see we can get more IO performance with the new patches.

Then, how the patches contribute to the improvements in this case.

split_buf_pool_mutex_fixed_optimistic_safe.patch

The patch splits global InnoDB buffer_pool mutex into several and eliminates waitings on flush IO and mutex when there is no enough free buffers. It helps if you have performance drops when data does not fit in memory.

Attention!(Windows only): You should not use with AWE. It is not tested at all…

control_io-threads.patch

Generally RAID storage can parallelize IO accesses to several disks. This patch enables to control the number of the IO threads on Unix/Linux and makes the threads to be used equally for parallel using. By default InnoDB uses
1 insert buffer thread, 1 log thread, 1 read thread, 1 write thread. With innodb_file_io_threads InnoDB will use
1 insert buffer thread, 1 log thread, N/2-1 read thread, N/2-1 write thread. You can start from “innodb_file_io_threads = 10″ for almost all RAID storages. The more disks the RAID have, the bigger number may make sense.

* This test uses “innodb_file_io_threads = 34″ (But, it is redundant value…)

control_flush_and_merge_and_read.patch

This patch makes more parameters about IO configurable. Normally, you may not need to configure the following parameters. But, in some extreme cases, it is worth to tune.

The following parameters are added.

innodb_read_ahead (default 3)

This controls [enable/disable] of read-ahead.
3: normal
2: enable linear read-ahead only
1: enable random read-ahead only
0: disable both

innodb_ibuf_contract_const (default 5) - Usual value
innodb_ibuf_contract_burst (default 20) - Burst value

The bigger value makes the more effort not to stock records to the insert buffer.
(Though, the more IO occur at the same time.)

The big value of “Ibuf: size” (like > 1000) may tend to losing the performance. If you have powerful IO system, you might set bigger values.

innodb_ibuf_contract_* is count of pages InnoDB pages tries to to
the buffer pool and merge the ibuf contents to them.

innodb_ibuf_contract_const is used during run a batch of insert buffer merge every 10 seconds, and
innodb_ibuf_contract_burst is used - comment from InnoDB code /* If there were less than 5 i/os during the one second sleep, we assume that there is free disk i/o capacity available, and it makes sense to do an insert buffer merge. */

innodb_buf_flush_const (default 10)  * Usual value
innodb_buf_flush_burst (default 100) * Burst value

These control the number of blocks flushed at once.
(flushing: writing modified db pages by flush_list order)

If you use extremely fast device (e.g. ramfs), the bigger value may help the performance.

* This test uses
“innodb_read_ahead = 0″
(The both of read-ahead are disabled)
“innodb_ibuf_contract_const = 50000″
“innodb_ibuf_contract_burst = 50000″
(For our workload it is better to not store many records in the insert buffer)

In conclusion, If you are using fast RAID storage, and/or observe performance decrease caused by shortage of free buffers you may try Percona HighPerf release.


Entry posted by Vadim | 7 comments

Add to: delicious | digg | reddit | netscape | Google Bookmarks

08:45 消息中心:让我们与您更好地沟通 » 谷歌中文网站管理员博客


您或许已经尝试过使用网站管理员工具更好地管理您的网站, 并在编制索引等方面与谷歌有更好的互动。不知您是否曾经留意到,在网站管理员工具控制台的右上方有一个“消息中心”? 自从2007年7月投入使用起, 消息中心已经成为谷歌与网站管理员之间一个越来越重要的沟通平台。为了让您对消息中心有一个更好的了解,本文将为您作一简要介绍。

作为网站管理员,您或许想知道,我究竟可以从消息中心读到什么样的消息呢?目前,谷歌只有在注意到某些问题时,才会向您发出消息,随着消息中心的逐步完善,将来我们会通过消息中心就更多类型的信息与您进行沟通。

如果我以前从未注册过网站管理员工具,我会不会错过了谷歌发给我的消息?这一点您无需担心。自从2008年3月起,消息中心开始支持“消息等待”功能,这项功能是专门为那些还没有及时注册网站管理员工具的站长们设置的。所有在这项功能发布之后发出的消息将会在您的账户中保存一年。也就是说,如果谷歌曾经向您所管理的某个网站发出过消息,即使您当时并未注册,只要之后您验证了对相应网站的所有权,您依然能够阅读到消息中心中的相应信息。

消息中心使您能及时收到来自谷歌的提醒信息,并与谷歌有更好的沟通。所以,为什么不现在就行动起来,注册网站管理员工具并验证您的网站呢?那样我们就可以将我们留意到的一些问题与您进行及时的沟通。如果您有其他疑问的话,欢迎您到网站管理员支持论坛寻求帮助。同时,非常欢迎您就消息中心提出您的宝贵意见和建议。

08:25 Message Center : It is all about your site :) » 谷歌中文网站管理员博客
By Fa Wang , Search Quality Team

You may have tried our Webmaster Tools for better interaction with Google and better management of your own site, but have you ever noticed the "Message center" at the upper right corner of the dashboard? Since its launch in July 2007, Message center has become a more and more important channel for Google to communicate with webmasters regarding your Webmaster Tools account and the sites you manage. To help you have a better idea of what the Message center is, here I'd like to introduce more about it.

What kind of messages could webmasters get from Message center? Currently you may receive the following kinds of message from Google, which may remind you in time and help you solve some problems regarding the sites you own. Over time we'll use the Message center as a communication channel for more types of information.
What should I do if I didn't get registered with Google Webmaster Tools before and possibly miss any message that Google sent to me? Don't worry. Since March 2008, Message center began to support "message waiting" feature for future owners who haven't previously registered with Google Webmaster Tools. Messages sent after the launch of this feature can now be retrieved for one year and will remain in your account. As soon as you verify your ownership of the site, you'll be able to access the messages (if there is any) even if they were sent before you get registered.

Creating a Webmaster Tools account and verifying your site gives you access to any message from Google and better communication with Google. So why not claim your site in Webmaster Tools right now so that we might give you a heads-up of some issues that we see? Should you have any questions, a great place to look for help is our Webmaster Help Group. Meanwhile, your feedback and suggestions for Message center would be very much appreciated.


^==Back Home: www.chedong.com

^==Back Digest Home: www.chedong.com/digest/

<== 2008-09-09
  九月 2008  
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
==> 2008-09-11