• Feeds

  • Archive for the ‘架构’ Category


    QCon Beijing qconbeijing全部演讲资料下载

    QCon Beijing 2009 qconbeijing slide download

    QCon全球企业开发大会(QCon Enterprise Software Development Conference)2009

    QCon 2009北京大会全部演讲资料下载 (包含pdf, ppt 等格式slide)

    永久链接:http://timyang.net/?p=136

    Update 2010/03/01: 目前Dropbox已经被封,请自行想办法解决。(点这里可申请Dropbox账号)
    Update 2010/05/11: 注意本文是2009年的演讲稿,QCon beijing 2010 的演讲稿官方尚未全部公布,部分下载见这里 http://www.cnblogs.com/coderzh/archive/2010/04/28/qcon-beijing-2010-ppt-slideshare.html

    http://dl.getdropbox.com/u/1080311/suncaoxipingqconbeijing-090423084840-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/augmentumshaorongqconbeijing-090423085848-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/vmwareliyanbingqconbeijing-090423084914-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/ebayrandyqconbeijing-090423080359-phpapp01.pdf 
    http://dl.getdropbox.com/u/1080311/pmlvjianweiqconbeijing-090423081337-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/uelvweideqconbeijing-090423091515-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/alipaychengliqconbeijing-090423080430-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/sprinthenrikqconbeijing-090423081310-phpapp01.pdf 
    http://dl.getdropbox.com/u/1080311/openwebdylanqconbeijing-090423091545-phpapp01.pdf 
    http://dl.getdropbox.com/u/1080311/youkuqiudanqconbeijing-090423080809-phpapp01.pdf 
    http://dl.getdropbox.com/u/1080311/azurewuyananqconbeijing-090423084537-phpapp01.pdf 
    http://dl.getdropbox.com/u/1080311/outsoftingqconbeijing-090423081254-phpapp02.ppt 
    http://dl.getdropbox.com/u/1080311/qcon2009intro-090412122012-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/youdaodengyiqconbeijing-090423072448-phpapp02.ppt 
    http://dl.getdropbox.com/u/1080311/freewheeldianeqconbeijing-090423080513-phpapp01.pdf 
    http://dl.getdropbox.com/u/1080311/reusearchpanjiayuqconbeijing-090423083708-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/collabortivecommercevisionwangqconbeijing-090423084739-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/tddmaitianzhiqconbeijing-090423083637-phpapp01.ppt 
    http://dl.getdropbox.com/u/1080311/QCon_Summary_Chinese.pdf 
    http://dl.getdropbox.com/u/1080311/flexmajianqconbeijing-090423090123-phpapp01.pdf 
    http://dl.getdropbox.com/u/1080311/geowebmoxiezhangqconbeijing-090423090510-phpapp01.pdf 
    http://dl.getdropbox.com/u/1080311/enterprisejavamaoxinshengqconbeijing-090423085404-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/doubanhongqiangningqconbeijing-090423080457-phpapp01.pdf 
    http://dl.getdropbox.com/u/1080311/taobaoyuexuqiangqconbeijing-090423085411-phpapp01.pdf 
    http://dl.getdropbox.com/u/1080311/aboutarchzhouaiminqconbeijing-090423080807-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/archqualitygaohuantangqconbeijing-090423080658-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/newinfoqchinaintro-090412122754-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/siemensliweiqconbeijing-090423080616-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/amazonjeffbarqconbeijing-090423083948-phpapp01.pdf 
    http://dl.getdropbox.com/u/1080311/ppwithagileyannhamonqconbeijing-090423081417-phpapp02.pdf 
    http://dl.getdropbox.com/u/1080311/jrubyluogudaoqconbeijing-090423085418-phpapp01.pdf 
    

    高性能网站经验-读杨建的Blog有感

    今天拜读了杨建的博客, 杨建开发的程序以高请求,高带宽为主,比如:

    开发的一系列系统中的两个 并发达到54.15w req/s , connections 340.25w  高峰一小时近20亿实际http请求处理量。

    所以整理了一些观点如下,喜欢吃快餐的请进。由于整理下面内容是跨十几篇文章的,就不一一给出链接了,需要看原文的简单Google一下即可找到。

    一 、如何衡量Web Server的性能指标

    总体来说同时在线connections和当时的每秒请求处理量是两个最重要的指标。

    实验环境数据: 杨建曾写了个HTTP服务框架,不使用磁盘I/O,简化了逻辑处理部分,只会输出 “hello world!”  程序部署在192.168.0.1上(2cup*4Core,硬件和系统都做过优化),在另外8台同等配置服务器上同时执行命令  ./apache/bin/ab -c 1000  -n 3000000   -k  “http://192.168.0.1/index.html” 几乎同时处理完毕,总合相加 40w req/s,他相信这是目前硬件水平上的极限值 。

    二、部署经验

    I. 对于cache处理的创新

    通过在url后面增加?maxage=xxx的做法,服务器通过这个参数来返回cache失效的maxage,比较灵活,优点:

    1. 可以控制HTTP header的的 max-age 值。
    2. 让用户为每个资源灵活定制精确的cache时间长度。
    3. 可以代表资源版本号。

    好奇,试验了一下杨建的系统
    $ curl -i http://sports.sinajs.cn/today.js?maxage=22

    HTTP/1.1 200 OK
    Server: Cloudia
    Last-Modified: Tue, 28 Apr 2009 14:10:02 GMT
    Cache-Control: max-age=22
    Content-Encoding: deflate
    Content-Length: 257
    Connection: Keep-Alive
    Content-Type: application/x-javascript

    大家可以看看返回的字段,其中有一点很有趣,返回直接不理http请求强制返回deflate(zip)格式, 比较霸道。

    II. IDC分布

    关于网络环境与IDC分布,正在迅速成长的公司可以了解下原文杨建介绍的经验,非常详尽。为什么说迅速成长的公司需要看,因为大的网络公司已经很清楚了,小的公司估计也用不上 :)

    III. DNS解析经验

    DNS解析有有个缺陷,每个单独域名里写在最前面的那个ip,它被轮询到的概率要比同组的服务器高10%,而且随着同组服务器的增多,这个差距会变大。所以最解析时候,每个IDC最好把硬件性能最好的服务器ip放在最前面。

    IV. 优化网卡, 调整内核参数

    这两段介绍也很有价值,主要是一些参数调优,做大型系统的推荐去看一下原文

    三、开发经验

    I. 关于epoll

    epoll最擅长的事情是监视大量闲散连接,批量返回可用描述符,这让单机支撑百万connections成为可能。
    边缘触发ET 和 水平触发LT 的选择:
    早期的文档说ET很高效,但是有些冒进。但事实上LT使用过程中,苦恼了将近一个月有余,一不留神CPU 利用率99%了,可能是我没处理好。后来zhongying同学帮忙把驱动模式改成了ET模式,ET既高效又稳定。
    简单地说,如果你有数据过来了,不去取LT会一直骚扰你,提醒你去取,而ET就告诉你一次,爱取不取,除非有新数据到来,否则不再提醒。

    自己用epoll写C的可以去深入了解下。

    II. 写数据

    顺便再说下写数据,一般一次可以write十几K数据到内核缓冲区。
    所以对于很多小的数据文件服务来说,是没有必要另外为每个connections分配发送缓冲区。
    只有当一次发送不完时候才分配一块内存,将数据暂存,待下次返回可写时发送。
    这样避免了一次内存copy,而且节约了内存。

    III. 如何节约CPU

    HTTP请求预处理 (预压缩,预取lastmodify,mimetype)
    预处理,原则就是,能预先知道的结果,我们绝不计算第二次。

    预压缩:我们在两三年前就开始使用预压缩技术,以节约CPU,伟大的微软公司在现在的IIS 7中也开始使用了。所谓的预压缩就是,从数据源头提供的就是预先压缩好的数据,IDC同步传输中是压缩状态,直到最后web server输出都是压缩状态,最终被用户浏览器端自动解压。

    IV. 怎样使用内存

    1. 避免内核空间和用户进程空间内存copy (sendfile, splice and tee)
    sendfile: 它的威力在于,它为大家提供了一种访问当前不断膨胀的Linux网络堆栈的机制。这种机制叫做“零拷贝(zero-copy)”,这种机制可以把“传输控制协议(TCP)”框架直接的从主机存储器中传送到网卡的缓存块(network card buffers)中去,避免了两次上下文切换。据同事测试说固态硬盘SSD对于小文件的随机读效率很高,对于更新不是很频繁的图片服务,读却很多,每个文件都不是很大的话,sendfile+SSD应该是绝配。

    2. 内存复用  (有必要为每个响应分配内存 ?)
    对于NBA JS服务来说,我们返回的都是压缩数据,99%都不超过15k,基本一次write就全部出去了,是没有必要为每个响应分配内存的,公用一个buffer就够了。如果真的遇到大数据,我先write一次,剩下的再暂存在内存里,等待下次发送。

    V. 减少磁盘I/O

    共享内存可以考虑用BDB实现,它取数据的速度每秒大概是100w条(2CPU*2Core Xeon(R) E5410 @ 2.33GHz环境测试,单条数据几十字节),如果你想取得更高的性能建议自己写。

    Ideas for creating a friendfeed like feed aggregator system

    I was invited to join a meeting about implement a friendfeed like feed system. Here are some ideas about requirement and architecture, which I typed on my BlackBerry during the meeting.

    1. Like the friendfeed, The product can import external RSS, so we separate the system into two parts. The rss crawl system and the feed pubsub system. The pubsub system has no responsbility to grab the feed from source. The feed itself only save feed summary and url.
    2. We decided to use the INBOX approach, which will push the published feed to be saved in all subscriber’s data table. More information of how this work can refer to Scaling a Microblogging Service – Part I.
    3. User’s homepage is an aggregation result. We choose to return a limited recent real-time date, no infinity pagination. But the user’s own feed(user’s profile page) may have a bigger date range.
    4. The unsubscibe logic have two choice, delete or keep the history data from one’s inbox. We decide to keep them.
    5. If the feed source had been deleted, do we need to delete all references in all subscriber’s inbox?  If need delete, each feed push to the pubsub system need to have a unique resource id. Another problem is after the source updated whether to publish a new feed or update the current feed?
    6. How to manage the group(QUN in Chinese) feed, deliver to all member’s inbox? Or share a group inbox?
    7. How to impl the feed comment logic, publish the comment to feed system or design a standalone comment system. We prefer to use a standalone comment system which doesn’t publish the comment back to the feed system.
    8. Every feed has a media type, such as text, video, image so the subscribe API can only retrieve a limited media type (text for mobile device). And a feed may have tags.
    9. The read/unread count is easy to implement. But the load is heavy. (QQ / QQzone may has such logic.)
    10. Need open API for 3rd party client(like twitter client), and RSS feed, may have OAuth integration.
    11. The storage may like friendfeed’s mysql schema (see How FriendFeed uses MySQL to store schema-less data) or use Amazon simpledb.
    12. May add support for XMPP Publish-Subscribe, or PEP(Personal Eventing Protocol) for pushing realtime time to users in the future.