• Feeds

  • 广州技术沙龙安排

    广州技术沙龙由一群技术人员发起并参与,旨在以技术的视角看待社会、互联网和未来,以务实精神深化交流,促进广州及华南地区互联网相关技术交流。

    时间:8月8日14点30分开始
    地点:新浪华南分公司会议室(可容纳20-50人) 广州市天河路208号粤海天河城39F (初定)
    本次活动无需费用。

    演讲的主题
    1.分布式key/value存储dynamo等分析(偏原理, Tim Yang)
    2.分布式xmpp系统(偏实践, Tim Yang).
    3.SNS开放平台openid/social/fb connect等(偏知识)
    4.Erlang,支持单台>5万并发用户的web前端服务器实践

    另外候选的主题还有
    网游服务器开发技术分享《选好业务和技术,单枪匹马做游戏》(赖勇浩)
    nginx 源码剖析(Joshua Zhu,下一期讲)

    因时间有限,本次活动最终只会讲一个主题,需参加者请提前邮件 iso1600 # gmail.com 报名,以便统计人数,并在邮件注明1.姓名 2.感兴趣的话题 3.您的Blog地址(Blogger优先考虑)。4. 邮件标题请写[报名广州技术沙龙],由于人数已满,报名已经截止。确认邮件会在周二(8/4)之前发出,没收到确认邮件的可以邮件询问。

    请关注 http://timyang.net/tech/guangzhou-salon-090808/ 以了解最新动态。

    广州技术沙龙设想

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

    目前碰到的问题:

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

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

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

    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。