Velocity 2011大会归来

获得更多信息,请关注我的新浪微博

http://weibo.com/jasseyyang

  

本周参加了北京Velocity2011大会:

http://velocity.oreilly.com.cn/2011/index.php

活动的相册见:
http://www.yupoo.com/photos/jassey/albums/4808409/

Velocity是关于:Web 性能和运维的会议,有国内外的一线互联网公司参加,如:Google,Facebook,淘宝,腾讯等,大家齐聚一堂讨论分享自己在工作中碰到的问题与经验。

--------------------------------------------------------------------------------

高性能移动互联网

 

每次会议都会有一个大的主题,这一次是移动互联网应用的性能问题,来自Google的Steve Souders,也就是:高性能网站建设指南(http://book.douban.com/subject/3132277/)一书的作者,给大家介绍了如何测量和优化移动互联网应用的性能,其中有一些不错的在线工具帮助大家做测量:

Mobile Perf
http://stevesouders.com/mobileperf/mobileperfbkm.php
书签形式的快捷入口,方便查看加载,Dom等信息,比较有用的是WebTiming,查看加载时间。

jdrop
http://jdrop.org/home
Json的云存储服务,方便在手机上收集数据,然后在电脑上查看分析。

blaze
http://www.blaze.io/mobile/
测量指点站点在不同移动设备上加载的工具。

PCAP
http://pcapperf.appspot.com/
分析移动浏览器网络信息的工具,介绍见这儿:http://www.infoq.com/cn/news/2011/01/google-pcapperf

同时作者针对之前适用于桌面浏览器提出的前端性能原则做了修正:
移动设备上的浏览器,因为最大连接数比桌面要小,需要尽量减少连接数。
因为网络的问题,特别需要考虑图片的优化,如针对不同分辨率的屏幕提供不同大小的图片。
同时因为现在的智能手机对css3支持的都不错,可以用一些css3的特性,来减少图片的使用
特别小的图片,可以用CSS3的 Data Uri来做,相关介绍见:http://dancewithnet.com/2009/08/15/data-uri-mhtml/
缓存部分,推荐使用HTML5的Cache和本地存储来做。

幻灯片在:
http://velocity.oreilly.com.cn/2011/index.php?func=session&name=%E9%AB%98%E6%80%A7%E8%83%BD%E7%A7%BB%E5%8A%A8%E4%BA%92%E8%81%94%E7%BD%91

--------------------------------------------------------------------------------

新一代Facebook移动平台

新平台的接口和功能
平台上移动应用的研发流程
平台为移动应用提供的传播支持

Facebook的DavidWei,他的演讲内容丰富,条理清晰,每次听的人都很多。

首先介绍了Facebook移动应用的增长情况:
增长量大
活跃度高
有大量的站点和应用连接到Facebook

然后介绍了Facebook移动设备上的信息传播渠道:
好友请求:点对点,针对性好。
用户Feed:一对多,类似于推荐,使用了某个不错的应用等。
以及Open Graph:一对多,类似于轻量级的Feed,用于访问了哪些网站,like了哪些餐馆,歌曲等等,谁做了某件事的表达形式,干扰少。

关于:Open Graph 的详细介绍,见这儿:
http://yogar.blogbus.com/logs/62725127.html

同时还介绍了facebook的JS界面库,登录,加好友,支付等接口。

在交互设计方面,作者也做了分享:

好友请求,同时推荐可能认识的人。
新的消息,在右上角,以红色数字的形式高亮显示。
用户Feed与推荐,在创建时,显示要发送的内容,防止应用开发者使用夸张的介绍内容。
多条类似的Feed会自动合并。
安装新应用时,告诉你有哪些好友也安装了这个应用。

这部分推荐看一下这本书:
社交网站界面设计
http://book.douban.com/subject/4909176/

DavidWei还提出了:Applications on multiple devices的观点,即你可以在不同设备上无缝的使用同一个应用,同时数据会共享。

这个有点像Kindle的用户体验,会自动同步书签和笔记,我们可以考虑在背单词应用上采用类似的设计。

幻灯片在:
http://velocity.oreilly.com.cn/2011/index.php?func=session&name=%E6%96%B0%E4%B8%80%E4%BB%A3Facebook%E7%A7%BB%E5%8A%A8%E5%B9%B3%E5%8F%B0

--------------------------------------------------------------------------------

快速的移动互联网网站与商业KPI的关系:来自一线的案例分析

介绍了在移动互联网环境下,性能对用户体验以及转化率的影响。

Joshua Bixby 首先介绍了从2005年以来
移动设备的变化情况,目前以IPhone,IPad,以及Android为主。
在facebook等社交站点上,移动设备所占流量的比例在加大。
来自移动设备上的支付也在增加,主要的例子有Amazon和eBay等。

同时以图表的形式,介绍了一个站点的流量来源变化情况:
完整的站点
wap站点
app应用

还举了一个实际的例子:
100个移动用户,其中有35个去了完整的站点,24个只看了一页就离开,有40个人看了一些页面,只有一个产生的购买行为。

如果从购买的比例来看,这儿的转化率就是1%,我们需要的是提高这儿的转化率。

从移动设备的统计方式来看,有JS脚本形式以及基于服务器日志2种方式。因为iphone,ipad,android等设备都支持js脚本,所以2种形式的比例差不多,有差别的是blackberry和Symbian,因为这2种系统的版本和设备比较复杂,对JS脚本的支持不是特别好。

网页加载速度,对于转化率的影响,作者举了个形象的例子:

15个人,要做一个需要5个步骤才能完成的操作,例如注册,假设每个页面速度都一样的情况下:最终有5个人完成了转化。

修改页面速度,让第一页加载很慢,结果,只有2个人完成了转化,很多人在第一页就被挡掉了。

修改页面速度,让第三页加载很慢,结果,只有3个人完成了转化,这次要好一些,大家愿意多等一会。

结论是首页的加载速度最重要,直接影响用户的最初体验。

在最后,作者还提出了一些自己的观点:
App应用的形式,只适合某些站点。
用户并不喜欢wap站点。
移动设备的访问速度,直接影响收入。

幻灯片在:
http://velocity.oreilly.com.cn/2011/index.php?func=session&name=%E5%BF%AB%E9%80%9F%E7%9A%84%E7%A7%BB%E5%8A%A8%E4%BA%92%E8%81%94%E7%BD%91%E7%BD%91%E7%AB%99%E4%B8%8E%E5%95%86%E4%B8%9AKPI%E7%9A%84%E5%85%B3%E7%B3%BB%EF%BC%9A%E6%9D%A5%E8%87%AA%E4%B8%80%E7%BA%BF%E7%9A%84%E6%A1%88%E4%BE%8B%E5%88%86%E6%9E%90

--------------------------------------------------------------------------------

来自淘宝的低功耗服务器定制与绿色计算

http://www.greencompute.org/
http://www.infoq.com/cn/news/2011/11/taobao-greencompute

介绍了淘宝的CDN系统中,使用定制的低功耗服务器的情况。

我的感觉有2点比较有用:
1 节省了空间,一个2U的机箱可以放8台低功耗服务器,每台机器为双核的CPU,4G内存,3块硬盘(1个SSD,2个SATA)。

2 能耗很低,看了介绍,只要25瓦。

结合我们自己的情况,我们目前会用配置较高的服务器做虚拟化,虽然总体运行比较稳定,但IO会是瓶颈,如果是重要的数据,还会担心稳定性的问题。而多数web和文件服务器等,平时压力并不大,这样可以考虑用这种小型的低功耗服务器来做,压力大的时候做负载即可。

如果有合适的商用解决方案,我们也可以考虑购买,查了一下,戴尔和惠普都有这方面的计划。

幻灯片在:
http://velocity.oreilly.com.cn/2011/index.php?func=session&name=%E4%BD%8E%E5%8A%9F%E8%80%97%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%AE%9A%E5%88%B6%E4%B8%8E%E7%BB%BF%E8%89%B2%E8%AE%A1%E7%AE%97

--------------------------------------------------------------------------------

上午主要是概念和趋势性的介绍,下午则会针对具体的问题做介绍。

比较好的有来自Facebook的DavidWei对于:移动互联网应用的性能优化

介绍了:
移动互联网的技术特点:从应用开发者的角度,哪些特点需要我们注意;
移动应用的性能:测量和优化移动互联网产品的一些方法和工具;
新技术的应用:HTML5为移动互联网产品带来的机遇和挑战。

首先介绍了桌面浏览器和移动设备上关注点的不同,移动设备需要关注耗电和安全的问题。

因为移动设备的网络通讯不是一直连接的,会在最后一次网络请求后过几分钟再断开,如果一个页面或应用,频繁的进行网络连接,会造成更多的网络连接开销,而这其实是可以优化的,建议是把多个操作放在一个请求里去做。

因为移动设备会使用很多公用的wifi信号,这就带来安全问题,别人可以通过抓包,来截取和重放已有的操作。为了安全,同时保证速度,可以考虑以下几种方式:

1 除了图片以外,页面请求用https加密的方式。
2 只在需要cookie验证的页面使用https加密的方式。

在桌面浏览器的情况下,我们会放置更多按钮,或滚动到页面末尾时,自动加载更多内容,这在移动设备上会产生问题:
1 加载更多内容后,dom节点数量会增加,占用更多内存。
2 页面内容多了以后,会影响滑动的速度和用户体验。
所以不推荐,或者需要有针对性的优化,如回收顶部内容的dom节点。

另外还介绍了如何统计DNS解析时间的小技巧:

随机数.facebook.com/test_pixel 空文件的形式,来统计dns加载时间。

关于如何收集和统计移动设备的型号,可以通过Agent来做,但移动设备的型号过多而且分散,这时可以用:

wurfl来做,wurfl是一个开源的移动设备浏览器agent数据汇总,xml形式,可以很方便的加载和处理,还有.net客户端封装。
http://wurfl.sourceforge.net/
http://wurfl.sourceforge.net/dotNet/
http://sourceforge.net/projects/wurfl/files/WURFL/2.3/

对于facebook来说,因为开发人员数量有限,为了尽快的推出各个平台上的应用,并保证界面交互的一致性,目前主要是采用app外壳,内嵌HTML页面的方式来做,也就是我们之前评估过的PhoneGap。

同时采用循序渐进的方式:Wap页面,3G页面。

为了方便调试,有2种方式:
1 修改Safari浏览器的Agent,访问移动页面,然后看加载情况。
2 http://phonegap.github.com/weinre/ 在移动设备里访问页面,通过Debug服务器,在桌面环境,看页面信息。
3 http://www.charlesproxy.com/ 代理服务器的方式,查看加载情况。

幻灯片在:
http://velocity.oreilly.com.cn/2011/index.php?func=session&name=%E7%A7%BB%E5%8A%A8%E4%BA%92%E8%81%94%E7%BD%91%E5%BA%94%E7%94%A8%E7%9A%84%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96

--------------------------------------------------------------------------------

基于应用场景的NoSQL选型与实践

介绍了奇艺网使用MongoDB和Redis的经验和心得。

和我们相关的主要是图片存储的部分:

图片-需求
单条长,不可变,最近最热
增量写,主键查
元数据:大小,尺寸,日期

用MongoDB存储时,推荐的方式是Doc,而不是GridFS,后者速度慢,内存占用大,并且有更多的操作日志。在1.8版本,单条记录最大16M,如果可以确认所有的文件都小于这个尺寸,就可以直接Doc形式存储,GridFS则没有这个限制。每个图片在存储时,还要有个uid信息,以方便分片。

同时还介绍了奇艺网储存用户播放记录的经验:

特点是:
写多读少,读写比 < 1:10
更新频繁:数据量小,oplog大
用户数据分散:浪费内存,多次seek

这个其实和我们的背单词应用有些类似。
1 用MongoDB存储时,设置同步时间为1小时。
2 关闭oplog,取而代之的是定时备份。
3 多个子记录合并为一条。

关于如何优化MongoDB的性能,好多是和MongoDB本身设计相关的,如:key的大小,锁定机制等,这块在幻灯片里有详细的说明。

作者还维护了一个NOSQL的网站:

http://blog.nosqlfan.com/

幻灯片在:
http://velocity.oreilly.com.cn/2011/index.php?func=session&name=%E5%9F%BA%E4%BA%8E%E5%BA%94%E7%94%A8%E5%9C%BA%E6%99%AF%E7%9A%84NoSQL%E9%80%89%E5%9E%8B%E4%B8%8E%E5%AE%9E%E8%B7%B5

--------------------------------------------------------------------------------

支持迭代计算的MapReduce框架

介绍了豆瓣的MapReduce 框架实现与应用。

具体的见幻灯片,我这儿记一下其中比较有意思的观点:

1 豆瓣使用了社区版的InfoBright,即列式数据库在做数据分析。

http://www.infobright.com/
http://bbs.tech.ccidnet.com/read.php?tid=244201

列式数据库在做数据分析时,有很多优点,存储空间和性能都不错。

2 网络带宽已经大于硬盘读取速度,所以豆瓣的框架,数据读取时,从一个中心数据库读取,而不是分布式存储。

3 在不是海量数据的情况下,比hadoop稍微慢一些,性能可以接受,并且近期会开源。

幻灯片在:
http://velocity.oreilly.com.cn/2011/index.php?func=session&name=%E6%94%AF%E6%8C%81%E8%BF%AD%E4%BB%A3%E8%AE%A1%E7%AE%97%E7%9A%84MapReduce%E6%A1%86%E6%9E%B6

--------------------------------------------------------------------------------

Web应用的加密算法实现缺陷与利用

介绍了不同加密算法的特点,与注意点。

其中举了PHPWind和Discuz!在加密和验证时的漏洞,这块有2个原因:
1 使用了自己的加密算法,这时往往思考的不够全面。
2 这2个项目都是开源的,这样相当于白盒了,别人可以通过代码级,寻找漏洞。

这样,其实也告诉我们,如果是使用第三方的内容系统,需要有人关注和跟进版本更新和漏洞,否则很容易被人扫到漏洞。

另外一个很重要的是,这种第三方的内容系统,在部署时,要尽量隔离。

幻灯片在:

http://www.slideshare.net/ph4nt0m/ss-10147512

http://velocity.oreilly.com.cn/2011/index.php?func=session&name=Web%E5%BA%94%E7%94%A8%E7%9A%84%E5%8A%A0%E5%AF%86%E7%AE%97%E6%B3%95%E5%AE%9E%E7%8E%B0%E7%BC%BA%E9%99%B7%E4%B8%8E%E5%88%A9%E7%94%A8

 

获得更多信息,请关注我的新浪微博

http://weibo.com/jasseyyang

 

 

posted on 2011-12-11 23:57 ji yang 阅读(...) 评论(...) 编辑 收藏

导航

公告

统计