September 2010 Archives

从 C10K 到 C500K

| 16 Comments

还在谈 C10K 的问题?这个已经过时了,现在大家已经开始说 C500K

国外的 Urban Airship 公司的工程师在其官方网志上发文章介绍他们在产品环境中做到 50 万并发客户端,Java + Pure NIO 的实现,最近又有文章介绍针对 Linux Kernel 调优的经验:Linux Kernel Tuning for C500k 。并且指出了"单个 IP 最大并发数量上限为64K" 只是一个误解。

硬件环境?操作系统为 Ubuntu(Lucid),租用 Amazon 的 EC2 ,使用 EC2 Large instances,64 位操作系统,每个 7.5 GB 内存。

当然,Urban Airship 是做手机消息 Push 服务的(Android Push 架构),所以,如果你也要做到这样的并发,还要看你的应用场景是否合适。去年了解到曾在新浪、腾讯任职的杨建已经做到超过 20 万的 HTTP 并发(现在可能已经突破这个限制了),非常的惊人。我非常想知道现在各个公司在这方面的实践数据。

--EOF--

另外参考:A Million-user Comet Application with Mochiweb

更新:杨建同学发来消息,去年已经单击突破 46.5万 Connections, 两块网卡, 1.5G 输出。10万请求处理每秒,每个响应 2k 左右。据说当时遇到一个坎一直没能过 50 万,不过这个坎三个月前已经过了,现在过 60 应该没悬念,四核双 CPU 机器。据杨建说,"按现在 4 Core * 4CPU 的机器,我觉得可以冲刺 80~100万,前提需要4块网卡(千兆)"。可见,把事情做到极致是没有极限的。

有过 MySQL 使用经验的人应该知道,MySQL 要想在线修改个 Schema 结构是个麻烦事,规模不大的表增加个索引造成的锁也可能导致整个 Web 应用宕机。这一点没办法和 Oracle RDBMS 、DB2 等商业数据库相比,甚至 PostgreSQL 也具备联机 DML DDL 的能力。我在过去写过一系列并不成熟的《MySQL 大企业级应用可行性分析》 文章中,也很是担忧这个问题。有些公司想迁移到 MySQL ,也因此而只能采取保守的做法。

不过现在这个缺陷临近被彻底修复。Facebook 的数据库技术团队将 Online Schema Change (OSC) 的代码开源,并且撰文进行了详尽的阐述。这是个很大的技术革新,Facebook 数千台 MySQL 服务器在过去增加个索引需要几个月的滚动升级,现在只需要几天即可。

MySQL 5.1 的 InnoDB 引擎具备 Fast Index Creation 的功能,在创建索引的时候无需复制整个表的内容,但是对于一定规模的大表增加索引,仍然需要花费大量时间,对于在线应用来说,仍然不可忍受。而 Facebook 的 OSC 则进一步进行了改进。对于 MySQL DBA 来说,这是个福音。感谢 Facebook 的员工 Vamsi Ponnekanti 的工作。如果要我说,年度 MySQL DBA 应该授予给他。当然,Online Schema Change 的部分代码从 Shlomi Noach 的 Openark Kit 中派生,建议 Shlomi Noach 一同获奖...

对于 MySQL 来说,我认为这是个里程碑式的时刻,无论 Oracle 将给与 MySQL 多大的投入,其它公司已经主动拿过接力棒。Facebook 技术团队再次立功了!

--EOF--

Update: Facebook 工程师在帖子里说了"Note that the above operations can be done within the storage engine itself, or using an external (PHP) script." 要知道,这并非只是一个 PHP 脚本的实现。我建议技术人员看帖子应该更仔细一些。也不要说这东西你早都想到了之类的技术阿Q的话,我倒现在为止没听到国内一个公司的技术人员做出来这东西。从想法到实现,其实还有十万八千零一公里呢。

MySQL Sunday 见闻

| 10 Comments

Oracle Open World 第一天一般是注册日加上 Keynote,但这次下午安排了 MySQL Sunday 的活动,这倒是 Open World 上第一次出现 MySQL 的活动,去年可能正在忙于和 Sun 整合,来不及安排吧。之前,搜索了一下议程,有两场 Facebook 的工程师的 Session,早早赶到会场,听完虽然感觉料不够多,但也很过瘾。

Facebook 进行分享的两位工程师分享的议题一个为 Advanced MySQL Replication Techniques ,MySQL Team 的 Harrison Fisk 是演讲人,另一个话题为 Success with MySQL ,分享人是 Mark Callaghan,他也是 MySQL Engineering Team 的 Lead,Facebook 有个 MySQL Performance Team,是介于运维护与工程师之间的团队。演讲的过程中除了 Facebook 之外只能听到 Google,其它公司或许不值一提,也或许是 Facebook 和 Google 渊源颇深的缘故吧。

Facebook 的数据库团队之所以能够维护几千台 MySQL DB,和他们对 MySQL 代码层的驾驭能力有很大关系,Facebook 自己就发布了不少 MySQL 的 Patch(在 Lunchpad 上可以找到),另外,Google 发布的 Patch 对他们来说也有很大帮助。此外,Facebook 也是当前世界上最大的 Memcached 用户,MySQL 的压力反而小了很多。基本上 DB 是用来做关系数据的存储以及跨 IDC 的数据同步。Faceook OLTP 环境的一些基本数据:查询响应时间 4ms ,写操作的响应时间为 5ms, 峰值每秒钟读取 3.5 亿行数据,修改行数为 350 万行,网络峰值吞吐量为 38GB,每秒钟应对的查询有 1300 万次。相当的惊人。大一点的表基本都进行了 Sharding,会后问了一下,Facebook 目前也没有使用 SSD,但是在做初步测试。

MySQL_Sunday.jpg
(这是 Facebook 之前的演讲现场,会场人不多,毕竟是第一天报到日)

会场同时也有其它关于 MySQL 的演讲,有关于 MySQL 5.5 新特性的介绍以及一些业界公司的 DBA 分享经验,可惜的是,人不算特别多,可能是听众目标不是集中的缘故吧。很多人的兴趣都还在傍晚时候 Oracle CEO 的主题演讲,当然,那些猛料这会儿大家应该都知道了。

--EOF--

JavaOne (图片)

| 2 Comments

有点孤独的 JavaOne:

JavaOne.jpg

上图是会议开始前的 JavaOne 宣传台。Java 的未来会怎样?谁也无从知晓。

有点动感的 JavaOne:

JavaOne_Sports.jpg

下午的时候有极限运动表演,观者众多。

Google 撤出 JavaOne了?但是 Lego pit 还在:

Google_lego.jpg

这是 Google 在 JavaOne 上唯一给人留下的印象了吧。

--EOF--

Oracle Cloud Computing

| 16 Comments

"It's nonsense and water vapor", 这是一年前 Larry Ellison 抨击"云计算"的话,而今天在 Oracle Open World 2010 的 Keynote 上,Larry 正式宣布 Oracle 进军云计算,当然,对于"云计算"他有自己的定义。之前就有传言这次 Keynote 有料,果然不差,至少比去年更为精彩。

现在进入云计算领域虽说有点晚,但 Oracle 进入云计算的市场毕竟在情理之中,产品线如此完整,总不能看着 Amazon、Salesforce 在 Oracle 眼皮底下赚钱吧? 网格(Grid)计算怎么说也有些过时了,而且这个概念实际上没什么大的影响。

在 Oracle Exadata Server 之后,本次宣布推出的软硬一体中间件产品 Exalogic ,虽说性能好得一塌糊涂(号称两套机器可以用来支撑 Facebook 的 HTTP 请求,当然,从数据上看是这样,实际上,考虑到带宽,那是不可能做到的),但价格也真是贵,不是一般用户能消费得起,莫非以后 Oracle 就走这种软硬结合的路线?

Oracle_exalogic.png

接下来,IBM 的压力估计不小,Oracle 现在俨然将 IBM 当作最大的竞争对手。

八卦:斯科特·麦克尼利这次似乎没什么声音,莫非有什么变化不成?且等各路小道消息吧。

--EOF--

这是一则只写给国内几百个 Movable Type 用户看的信息。

Movable Type 5 的用户可能会遇到关于留言功能的一个小Bug,系统在用户留言的时候提示留言失败(实际上留言已经成功),"wide character in subroutine entry",搜索后可以参考这则 信息 以及 困扰已久的 MT5 的 bug 解决了,但对于没有使用的 Markdown 插件的用户,这两个地方提到的办法只是给了一个思路。更合适的解决办法是打开 MT 的 Debug 模式,然后提交留言,系统提示信息可以让你发现具体是哪一个脚本出错,这次遇到的是 EncWords.pm 176 行提示错误。

于是,修改该文件,在开头加入:

use Encode qw(encode_utf8);

将 176 行的代码:

encode_base64($str, '');

修改为:

encode_base64(encode_utf8($str), '');

重新提交留言测试。MT 5.01、5.02 与 5.03 测试通过。

说句题外话,Movable Type 日渐式微,国内用户也是越来越少了。如果不是用 Perl 开发,比如用 PHP ,可能现在也未必是 WordPress 的天下。基因决定命运,对某些创业企业来说是这样。

--EOF--

更新:后续的几个版本也有同样的问题,需要手工修改一下。Movable Type 越来越没落了。

狗日的中国移动

| 75 Comments

我想只要使用中国移动无线数据套餐的用户,都可能有在流量超出额度的时候被扣掉不菲的费用的经历。

在 9 月 1 号我通过 Twitter 以及 新浪微博腾讯微博 发了这样一条信息:

"中国移动在无线数据业务收费上表现得非常流氓。一旦数据流量超出套餐限额后,在不通知用户的情况下直接用 1分钱/Kb(有些地方是三分) 扣除用户的费用,简直是个收费陷阱。我想很多人遇到类似的情况吧?你大爷的中国移动"

之所以这么火大,是因为刚好30号晚上我去看《盗梦空间》首映,结果用了一会儿手机,就被通知余额不足尽快充值的提醒。心想奇怪,几天前刚充了一笔话费怎么这么快就用没了?到了第二天上午有人电话不到我,才想起充值,原来当天晚上就被停机了。停机事小,但前一天预定的机票因为订票方联系不到我,导致我重新订票反而又多花了几百块钱。

发出消息后,从众多有过类似经历的推友们得到的反馈是:1) 非常多的移动用户被这样扣过不菲的费用,绝大多数人不了了之;2) 上海和北京等部分地区是默认开通流量短信通知的,但是我所在的浙江地区,默认是不开通这个通知服务的;3)有些地方的流量超出1Mb是一元人民币,有些地方则是 1Mb 流量10 元人民币,我被扣费则属于后者这个价格段。4)投诉,成功的话可能会返还一部分费用。

有好几位推友写了他们投诉的经历。出于愤怒,我也进行了电话投诉,开始客服人员给我的答复是费用已经扣了,没有其它办法,后来我质问为什么当初开通这个服务的时候可没被告知有什么流量通知服务?甚至通过网站设置也没有看到有什么地方告诉我可以设置通知?为什么上海地区则可以自动通知用户?最后移动客服告诉我说,这个事情 48 小时之内会给我答复。第二天,移动客服给我电话,说超出部分按照套餐计费,其余的将在几个工作日内返还给我。

补充投诉要点:1)移动是否有流量通知?在流量用尽的时候是否有给用户的选择?2)为何其它地区自动开通通知服务? 3)办理服务的时候客服人员或是网站信息是否有明确提示? 4)你可以到工信部网站进行进一步投诉。

对我个人来说,这实际上已经是第二次被这个陷阱扣掉费用,上一次的时候自己没想这么费事,不了了之。其实就是用户怕费口舌,反而让这个陷阱一直存在到现在。之后的几天,我居然又在微博上看到有几位朋友再次中招。

这里转帖一下新浪微博上的 @ImCola 带来的提示:

如果您满足以下条件:浙江移动用户,开通了GPRS流量套餐;请立即发短信3031至10086,开通免费短信提醒功能。在流量套餐剩余免费流量为5M、1M、0M的时候会收到短信提示。

另外 @hutuworm 也提示我有个"手机上网安心宝"可以用来"省钱"。中国的消费者简直是把移动惯坏了。

我相信这么多用户的反馈,中国移动内部不可能不知道这个事情,实际上自动为用户开通提醒,从业务和技术角度来看都没有什么难度。为什么中国移动仍在很多地区不这么做?合理的解释可能只有一个:这里面能为中国移动某些分公司,某些部门带来利润,大量的利润!

在这里我想对那些被扣了不菲费用的中国移动用户说,如果你遇到同样的情况,请直接拨打移动客服热线,维护你的消费者权益。不要忘了有一位伟大的中国人说过"你不给我一个说法,我就给你一个说法",我们来一起对霸王条款说不!

公开数据显示,中国移动2009年利润1151.66亿。不知道这里面有多少是利用类似收费陷阱吸金的。中国移动如果还想有点社会责任,应该就这个事情给个说法。

如果中国移动能够公布每年因为流量超出套餐额度对用户多收取的费用,届时,我也将就这个标题向他们道歉: 中国移动不是狗日的。

--EOF--

补充:因为各地资费差异,扣费的数据会有所出入。但这个不会影响整个事情的结论。另外,联通据说也不干净。最后,"狗日的中国移动",不是我的发明,你去Google搜索一下,已经有 35 万结果可用。中国移动如果要告消费者诽谤,请从 Google 找到的结果一一告起。

Updated:2011 年 1 月 10 日,今天得知,上个月狗日的移动又扣了我将近 300 元数据费用。再次投诉。

3PAR 争夺战

| 3 Comments

这两天看到消息,Dell 在对 3PAR 争夺战中退出,HP 宣布获胜。当然,代价也是不菲,总收购价格大约 20 亿美元。

3PAR 这家公司刚进入国内我就有所接触,因为该公司在美国有很多证券、金融行业的客户,加之我上一家雇主就是做这个方面的,所以我非常想了解并引入 3PAR 的一些成功的经验,并且研究了一下高端的几款产品特性(refer: 3PAR 存储架构解析 ),最后还吃了一下螃蟹,在 3PAR 上实现了一套 Oracle 11g RAC 集群。所以,我算得上国内少数真正用过 3PAR 的了吧。考虑到以后再也不会接触这些所谓高端存储,还是有必要写点东西做个纪念。

应该说,3PAR 这产品的确有独到之处。首先是性能上看,通过特定硬件架构,充分利用了机械硬盘的特点,进而保证 I/O 响应时间,这是硬指标,真是非常贴近金融类的用户需求。 Thin Provisioning 技术也是实实在在的可在产品环境使用的,不像个别存储厂商只是一些功能的包装,跟风炒作概念,忽悠客户。让人感慨的是,3PAR 最近有有些生不逢时或是走向末路,上市时也恰好是金融危机来临之际,核心业务一下子受到非常大的影响,这是商业层面上的;另一方面,3PAR 的技术在机械硬盘时代几乎独步存储武林,但到了 SSD 的时代,则有武功被废的可能。尽管也宣称支持 SSD,但毕竟在机械硬盘时代的优势将不复存在了。追求高 IOPS ,更小 I/O 响应时间的用户用 PC 服务器 + SSD 就能很好的满足要求了。

HP 收购 3PAR 的意图其实比较明显,那就是弥补自己在高端产品上的缺陷。最近几年,IBM 在推收购来的 XIV ,HP 也有 EVA 系列的存储,和 3PAR 的一些设计理念都是很相近的,不过都只能算是中端存储,算不得高端产品。据我所知,EVA 似乎市场表现一般。收购 3PAR 后,估计 EVA 产品线将最终消亡。业内其实都知道,HP 自己一直没有高端存储产品,一直是 OEM Hitachi Data Systems(HDS) 的高端产品,后来和 Oracle 合作 Exadata ,Oracle 收购 Sun 之后也不再和 HP 合作,对 HP 来说,如果在未来几年,要在存储领域有所作为,收购是最为便捷的办法--也是高层最不用动脑筋就能使用的办法。

尽管 HP 有收购 3PAR 的足够理由,但我觉得这笔收购未必能对 HP 带来多大价值。如果给 Dell 可能会更好一些,Dell 可能将 3PAR 用来主打中高端存储市场。

据说 3PAR 的 CEO 获益比三位联合创始人的都要高,这就是商业运作的力量。3PAR 发展到现在,历史已经有 10 年了,在看到一些有创造力的公司成功之前,也要想到创业的艰辛,成功只是少数,失败是多数。(3PAR 的命名是这样的:3 表示三个人,P 代表Jeffrey Price;A 代表Ashok Singhal;R 则为 Robert Rogers,已于 2001 年离开. 所以,这家公司的名字应该都用大写字母才是)

从技术发展和业界的需求来看,这些 SAN 中高端存储已经临近黄昏。也不可能在云存储方面有什么进一步的想象力,有的话,也是空想。当然,这是另外的话题了。

--EOF--

盗梦空间(Inception)

| 16 Comments

看过之后才会相信,电影《盗梦空间》(Inception) 如潮的好评名副其实,个人强烈推荐。即使有人介绍过剧情,自己观看的时候仍然是不一样的。这就是经典的魅力吧。

整部电影还是给人颇有些"庄生晓梦"的感觉。我和 Laura 开玩笑,是不是现在就在梦里?毕竟都凌晨三点钟了。情节繁复,循环,仿佛博尔赫斯的小说,但影片倒是并没有故弄玄虚,虽然开头部分信息量较大,一旦进入情节,后面的节奏控制得非常好。对于情节的设定,计算机同行不妨把把梦当作虚拟机好了,只是下一层的虚拟机会更慢而已。或许你会为电影中的爱情故事感慨,关于父子亲情难道就不感人么?

有一处场景明显是借鉴了荷兰艺术家埃舍尔(M.C. Escher)的作品,"不可能"的图形:

Escher Ascending and_Descending

杭州万象城的 IMAX 厅,九月一号凌晨看的首映,买票的时候有些犹豫,午夜场,第二天还要上班,熬夜值不值?回家睡了一觉又杀去,整个放映厅差不多都坐满了,杭州影迷精神头可谓十足。将近三个小时的电影,看完后毫无困意。

--EOF--

关于这篇归档

This page is an archive of entries from September 2010 listed from newest to oldest.

August 2010 is the previous archive.

October 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.