• Feeds

  • Archive for July, 2009


    广州技术沙龙设想

    最近看北京beta技术沙龙Beijing Open Party举办了多次非常有价值的技术讨论。上海前不久也有TopLanguage的小范围7月4日聚会。广东的技术圈相比之下就显得有点落寞,因此最近也小范围同一些本地网友有过交流,希望也能有本地的定期技术活动,增进本地技术从业人员交流,分享有价值的技术经验以及开展更多深层次的技术活动。 话题初步设想以互联网相关技术为主,包括编程语言,架构设计,数据库,分布式等。

    目前碰到的问题:

    • 暂无强势的本地论坛及讨论组来讨论技术活动,即使很多本地网友有聚会意愿,也没有很有效的渠道去传达到这些用户
    • 没有偏技术及IT主题的线下咖啡馆固定场地,这个相对障碍较小。
    • 本人对组织技术类的聚会也缺乏经验,如果有经验的人愿意参与来组织当然更佳。

    场地以广州为主,深圳也不排除。

    希望有意向的朋友献计献策。可发邮件给iso1600(at)gmail(dot)com,或DM给[email protected],也可直接在本文留言。

    Update: 赖勇浩同学在Twitter上提议8月8日举行一次聚会(需翻墙查看),我深表赞同,对主题有建议的可留言或请按上面方式与我联系。

    Update 2: 人数暂定50人以下,同时增加游戏服务器的Topic, 包括MMORPG, WebGame, SocialGame等。有意向的同学可以发邮件预报名参与或演讲。

    欢迎转发本文到各技术论坛、讨论组及QQ群等。

    关于阙宏宇lighttpd与mod_cache在twitter上的一些讨论

    6月28日的beta技术沙龙上阙宏宇介绍了lighttpdmodcache,视频及slide在 http://club.blogbeta.com/76.html,modcache是阙宏宇开发的一个lighttpd module, 它在部分程度上可以替代squid。在活动的介绍上提到

    lighttpd是基于事件驱动的高性能web服务器。mod_cache是在lighttpd上运行的缓存插件。lighttpd+mod_cache 搭建的缓存系统,具有配置简单,性能高,在很多大型系统得到了广泛应用。本次活动由mod_cache作者阙宏宇介绍lighttpd的基础知识,讲解 lighttpd高性能的原理,讨论lighttpd的扩展编写方法等高级话题。也将分享mod_cache插件的特点和使用经验。

    在看视频的过程中我在twitter上也分享了阙宏宇的一些观点,同时也引起了一些网友的关注及讨论,部分内容摘录如下(下文每行开头的链接是发言人的twitter ID)

    xmpp: 刚看到阙宏宇的lighttpd mod_cache视频,他的调优建议把keep-alive设成=0(相当于关掉),个人不是很认同

    xmpp: 阙宏宇称”使用lighttpd+mod_cache比squid快一个数量级,原因是lighttpd用event/file, squid用thread/db“ 视频第41分钟

    xmpp: 阙宏宇最后说web server使用多线程是倒退,并拿memcached单线程跑得很好来证明。但是我觉得并不能单纯这么考虑,一是多核CPU被浪费,二是web server(io密集, 慢连接)和cache server特性有区别不能简单相提并论。

    SnaiX: @xmpp 我觉得阙宏宇的言论很有问题,首先所谓的event based也是需要较大消耗的,且,squid有n中模式可以选择,包括了所谓的db based files based。

    xmpp: @SnaiX 是阿,他的软件对于某些场景可能有意义,但是大部分情况还是没法代替squid的,视频最后Q&A也看到,比如没法实现合并多个相同资源的并发请求等

    xmpp: @eishn: “对于任务的处理, 不可避免会涉及到 multithreading 的问题” 是 @yingfeng 提到的,在我的理解,“任务”是指为了返回请求,需要消耗cpu及io等待,直至输出内容返回网络这个执行过程

    yingfeng: @xmpp 读过POSA II便可知道event based只是解决了acceptor端的问题,对于任务的处理,不可避免会涉及到multithreading的问题

    xmpp: @SnaiX: 批评多线程者无非就是批评锁,所以1最极端者就用单线程,2退一步者就线程不共享内存,线程间用消息通讯,3普通多线程通常加锁,因此会带来等待锁(其实Semaphore锁对等待线程没什么开销的)及线程切换开销,因此开发多线程程序只要了解底层原理就没什么恐惧的

    xmpp: @eishn 你说的是实现方法是协程吗,我倒很想看到你说的实现方法详细描述。如果是协程,它虽然避免了锁,但还是存在切换开销,而且也不能随时切换,我觉得如要利用多核优势,多线程是大势所趋

    alpha86: @xmpp 静态文件的请求可以开keep-alive, 动态请求的话其实keep-alive起不到多大效果。

    Joshfeng: @xmpp 我个人觉得keep-alive的设置要看服务器上主要是什么类型的文件

    xiaoxiaolu: RT @xmpp: … 他的调优建议把keep-alive设成=0(相当于关掉),个人不是很认同//就web而言,我挺认同的

    mikespook: RT: @xiaoxiaolu: RT @xmpp: 刚看到….调优建议把keep-alive设成=0(相当于关掉),个人不是很认同//就web而言,我挺认同的// 具体情况具体处理,keep-alive 对小文件友好,对高并发不利~

    rockyzh: @xmpp 同意,现在已经进入多核时代了,当年的squid以高效的单线程著称,现在可得改改了

    TerryTsui: RT: @xmpp: 阙宏宇最后说web server使用多线程是倒退,并拿memcached单线程跑得很好来证明。。。 //memcache 也可以是多线程跑啊

    xiaoxiaolu: RT @mikespook: RT: @xiaoxiaolu: RT @xmpp:调优建议把keep-alive设成=0,个人不是很认同//我挺认同// 具体情况具体处理,keep-alive 对小文件友好,对高并发不利~//高并发看情况,若跳出率很高,就关掉,省事的话,一律关掉

    SnaiX: @xmpp 在他视频20分钟左右的位置,提到squid和lighty的比较。提到“能不用线程就不用线程,尤其是几个线程在做同一个事情,用这种事件驱动的模型更好“,我不赞同,这种并发的目的就是用来做同一个事情的。其次就是线程模型和事件驱动一点也不冲突。

    SnaiX: @xmpp memcached的模型明显是比较简单的模型,为了实现方便而已。所以mc这种东西如果你不适用线程模式或者不对其进行一些特殊优化, 是很难用来吞吐大数据的,因为单线程会使得在write较多数据的时候占用的CPU时间太长,从而直接影响了对别的请求的响应。

    tangfl: @SnaiX @xmpp snaix 应该大力推销一下 csf 模式:前端 event driven,中间任务队列调度,后面线程池处理,完美了。。。

    eishn: @xmpp 阙宏宇说webserv使用多线程是倒退,基本赞同。不过其mcachd例子不妥,常规evt负载亦不低。然单线程异步io性能甚于多线程,高并发场合由 是,故多线程非最佳。然实现逻辑,多线程是最易用的,故最佳形式是以模拟多线程写逻辑,而以单线程异步实现,这也是我的做法。

    jiaojing: RT: @jeffz_cn: rt @xmpp RT: @yingfeng: @xmpp 读过POSA II便可知道event based只是解决了acceptor端的问题,对于任务的处理,…//多线程也只是用来做cpu时间片的分配,协程也是一个不错的选择.切换代价更 小

    SnaiX: @xmpp 我认为,如果仅仅是为了避免多线程所造成的程序复杂度上升而在该使用多线程的地方却不使用多线程,是一种无能的表现。譬如说,有言论说:多线程造成你的程序一旦有问题,整个进程就core dump了,所以不稳定。可关键是,你的程序应该有问题么?

    SnaiX: RT @tangfl: @SnaiX @xmpp 其实CSF也没什么可高深的,只是我觉得需要有这么一个东西,这样很多东西就可控了。做技术的,不能整天靠凑合来凑合去的过日子。

    eishn: @xmpp stackless python 协程可以做到随时切换, 不过不能达到 erlang 那样的协程级别的多核分配, 尽管可以由用户自己非原生实现。协程虽然还是有切换开销, 但是没有无谓切换, 只在类似 io 等待的场合下才会发生切换, 所以切换次数远小于线程。

    jiaojing: RT: @eishn: @xmpp stackless python 协程可以做到随时切换, 不过不能达到 erlang 那样的协程级别的多核分配, …。// erlang的smp也是用多线程(一个核一个线程,ps保证)跑多个scheduler.

    flierlu: 多线程领域也是在不停发展的,近几年 lock-free 和 wait-free 算法逐渐成熟,加上线程局部内存池等等技术,只要设计上不出大问题,肯定能超越多进程

    zhuzhaoyuan: @xmpp: @yingfeng: 读过POSA II便可知道event based只是解决了acceptor端的问题,对于任务的处理,不可避免会涉及到multithreading的问题 || 反对,要看服务类型是IO密集型还是计算密集型的,IO密集型的不需要多线程。

    附加说明

    • 在Twitter中,@表示reply某人, 类似email中的答复,RT表示retweet,类似email中的转发。
    • 从上面看到,Twitter在讨论上处理线索功能上还是比较弱,需要重复RT原文来串联上下文,很需要类似gmail那样conversation的功能。
    • 我的twitter ID是xmpp,欢迎大家follow。

    Facebook平台设计(二)

    上个月介绍了Facebook平台设计(一),再继续看f8 2008。f8平台推出在短短一年的应用开发者已经超过40万。keynote继续由Facebook创始人兼CEO Mark Zuckerberg主持(视频),Mark介绍了一年中不少成功的应用案例,如iLike推出4天就增长到100万用户,以及 livingsocial, Zynga等成功案例。主要的议题包括

    一、Facebook Connect

    Facebook开放平台之后围墙的问题依然存在,所有的用户所有的内容都在facebook网站的内部。facebook connect可以将facebook的用户,好友,feed和第三方网站作深度整合。将social graph扩大到所有的Web领域。到目前为止Facebook Connect的应用已经非常广泛,比如6月27号的Facebook Developer Garage Shanghai介绍了不少基于Facebook Connect的网站,如提供给外国人分享在上海活动图片的citymoments就非常不错。

    二、Facebook新的设计

    Mark介绍了很多Facebook新的设计, 比如应用可以不再局限在profile box里面,可以作为一个独立的profile tab, 相当一个独立的页面,应用开发商有更多独立的发挥空间。
    另外facebook开放了翻译工具, facebook的翻译工具可以让全球的用户帮助将第三方开发的应用翻译成各种本地语言,并由用户投票每个条目最合适的翻译结果。这个本来用于facebook平台自身的国际化,此次开放给第三方开发者。

    三、平台指导原则

    f8 keynote后半部分由Benjamin Ling主讲(视频),Ben也是一位神奇的人物。他本来在Google当产品总监,2007年跳槽到facebook做Director of Platform, 不过好像现在又跑回youtube去了。Ben是亚洲面孔,不知道是不是华人。他介绍了facebook平台的三大指导原则(Guide principle for great social app)

    1. meaningful/有意义
    a. social(graph), e.g. Green Patch
    b. useful/有用,如Carpool
    c. Expressive/表达, Graffiti, draw on friend profile
    d. Engaging, 比如2008/5,用户投入在playfish上的时间有9亿分钟。

    2. trustworthy/信任
    safe/安全, trusted
    secure – 平台越提供更多的privacy控制, 用户才会产生越多内容
    respectful
    transparent

    3. well designed/良好的设计
    clean, facebook平台确实很干净,值得陈赞, 因此平台要求应用也如此。
    fast, use more, 访问速度越快,用户用得越多。
    robust, 强壮

    原则总结起来就一句话,”keep the ecosystem safe for user, fair for developers“, 平台设计的目标是对用户安全,对开发者公平。

    12