Tag Archives: C10K

从 C10K 到 C500K

还在谈 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块网卡(千兆)”。可见,把事情做到极致是没有极限的。

此文作者:, 位于 Arch 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

优酷网(Youku.com)架构经验

这次 QCon (北京)会议网站架构案例分析这个 Track ,虽然话题不多,但课程设计时候考虑覆盖的面还是比较广的。作为视频网站代表,优酷带来了一场包含不少实战经验的技术分享。邱丹(优酷网开发副总裁,核心架构师)可能公司的事情比较忙,一直到第二天中午才赶到会场。还半开玩笑说,’怎么这么多人,还以为是小型的会议呢’…

Youku_Qiu.jpg
缓存

缓存黄金原则:让数据更靠近 CPU

CPU-->CPU 一级缓存-->二级缓存-->内存-->硬盘-->LAN-->WAN

讲到了 Youku 自己的内部项目,针对大文件缓存的。目前开源软件中,Squid 的 write() 用户进程空间有消耗,Lighttpd 1.5 的 AIO(异步I/O) 读取文件到用户内存导致效率也比较低下。Youku 不用内存做缓存(避免内存拷贝,避免内存锁)。值得注意的是,缓存技术容易被滥用,也有副作用,比如接到老大哥通知要把某个视频撤下来,如果在缓存里是比较麻烦的。

数据库

优酷对数据库 Sharding 做了不少尝试,而且实现效果应该不错。DB 读写分离上有比较丰富的经验。

Youku_Sharding.png

为了提升数据库 I/O 能力,启用了 SSD 。6 块 SSD 做 RAID 。我在 Twitter 上发了一则 Youku 使用了 SSD 的消息,很多朋友以为是用来存储视频文件,这里需要澄清一下–只是局部使用。

网络吞吐量优化

这是我强烈要求加上来的一节内容。网络优化,视频网站肯定都做得不错。这一节的关键词是 “事件(event)驱动”,令人深刻的一句话是 “ePoll 推动当今 Web” ,的确,现在很多比较热的 Web 组件都是以 ePoll 为卖点。

延伸阅读: The C10K problem (我一直想翻译一下这个页面,苦于腾不出时间) 与 Libevent 如果做互联网,遇到扩展性问题,这两个信息点还是避不过去的。

最后一个例子是针对 Memcached 的 Agent 的,这一点和 Facebook 架构中的 Memcached 处理可以对照来看。

演讲结束的时候,有人提问优酷对视频缓存上有什么特别的地方? 回答是一个大视频可能分成多个小文件,这样缓冲的时候就效果更好一点–(并行啦)…其实访问优酷的确比土豆快那么一点点。

EOF

PPT 过几天 InfoQ 中文站会发布。稍安勿躁。