车东[Blog^2]

按此阅读全文 "AWStats的补充定义：区分百度图片搜索和一些新出现的流量较大蜘蛛" »

在前一期山寨交流会上：桂新说他会将良好的构架和一套完整的监控系统作为两个非常重要的基础来抓，良好的架构一步到位这点很难做到（对于发展速度并不确定的小公司来说，架构过大也是一个成本上的风险），但对于后者：一套完整监控系统我是非常认同的。对于目前普遍缺乏测试的Web应用开发过程来说，监控几乎就是测试很重要的一部分；而系统监控本身，也可以帮助及时发现很多问题并量化优化的效果。而系统的扩展和调优的大部分技巧都可以从《构建可扩展的Web站点》(作者是Flickr的开发者)一书中看到。为了减少不必要的调优（盲目的调优是危害很大的），建议从这2章开始看起： 第8章《瓶颈》发现和第10章《统计数据，检测和报警》；有了这些瓶颈检查结果和统计监测/报警系统后，再有针对性的看其他章节做系统调优。

以下是我在博客大巴开发中的一些实践小结：
1 数据库相关
1.1 系统应用层面出问题我一般都习惯性的先去看数据库群的连接数统计：大部分应用最后的瓶颈都在于单表数据量过大后，数据存取慢导致的并发连接数过多的问题，
1.2 解决这个问题目前的主要策略就是分片(share nothing)，单个数据库连接数超过100，就想办法拆分并用多个daemon提供服务，数据的拆分也降低了单表的数据量；
1.3 对于需要全局访问的数据，通过另外冗余存储一份专门用于全局对比的操作用（会增加数据一致性开发量）；
1.4 slowquery一般是遇到问题才去看的，其实binlog转换成文本格式后，也可以用mysqldumpslow统计的，slowquery就是执行时间超过一定阈值（缺省是1秒）的binlog，更全面查询统计，则需要打开数据库的query log，binlog其实就是没有只读操作的querylog；

2 日志相关
2.1 对于应用来说：容忍过多的非致命错误容易让错误日志变得非常难读，从而对发现很多致命错误造成麻烦；在各种系统开发间隙，统计各种错误日志也是我非常乐于去做的一件事儿，从warning faital级的PHP错误信息到404错误日志；报警后的急救车固然重要，日常的体检及时发现潜在风险较高的漏洞或缺陷并修正都会在系统真正发生报警的时候为成功抢修节约大量时间；
2.2 经常出问题的环节要有错误日志，并且格式设计的比较便于sort和grep也是很重要的一方面；

3 需求削减：
3.1 并非所有用户都需要被满足： 发现spammer和盗链者，并设法降低资源流失的速度；
3.2 通过日志统计发现用户使用较少但对系统负载很高的功能；

此外：一个管理方面问题： 开发过程本身是日志是最少的，怎么解决？

按此阅读全文 "推荐《构建可扩展的Web站点》- 基于监控的系统调优 " »

是几周前跆拳道活动后，同事问的我一个心理测试题；

你的反应是什么？这个测试的来源我没有查到，因此也无所谓标准分析结果。

按此阅读全文 "[心理测试] 在一个伸手不见五指的黑屋子里，你会做什么？ " »

上周又召集上海互联网小业主做了一次山寨技术交流会，前3次都是博客大巴做东； 这次的一个主题由Sun的工程师向我们介绍了：Web20kit，并征求反馈意见；

觉得对于小网站来说： 最需要的是以下几类技术/服务
1 可扩展的存储硬件或服务：目前大部分公司还是用nfs+盘阵的模式做存储，在备份/容量扩展方面，很多都是需要结合应用修改来实现的，如果Sun能在国内做Amazon S3那样的存储中心，我们还是信得过的；
2 全文检索Lucene应用包： 对于很多以PHP为主要开发工具的小公司来说，只是为了lucene掌握java成本还是比较高的，之前我尝试过XML接口，现在感觉有一个Json in / Json out的方案也是会很有用的；
3 关键词过滤引擎： 其实旁路监听，动态屏蔽的模式已经是非常先进的理念了，昨天见了一次Rebecca，过滤需求其实是非常有中国特色的；
4 系统安全检查咨询：FABAN能否扩展为一个安全漏洞检查工具？安全的检查也是我们非常关心的；
5 MySQL 急救中心： 大部分网站出了数据库问题的时候已经没有时间学tracking tool了，SUN的工程师赶快过来吧，如果最后能解决1500￥/小时也是有市场的；

按此阅读全文 "互联网小业主的急需什么技术解决方案？ - 给Sun Web20kit的建议" »

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write("\<script src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'>\<\/script>" );
</script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-69476-1");
pageTracker._addOrganic("baidu","word");
pageTracker._addOrganic("soso","q");
pageTracker._addOrganic("vnet","kw");
pageTracker._addOrganic("yodao","q");
pageTracker._initData();
pageTracker._trackPageview();

document.onclick = function(e) {
    e = e || event;
    var el = e.target || e.srcElement;
    if ( el.tagName=='A' ) {
        pageTracker._trackPageview("\/clickto/" + window.location.href.replace("http:\/\/www.chedong.com/", "") + 
            el.href.replace("http:\/\/", "\/"));
    }
}
</script>

按此阅读全文 "基于Google Analytics的点出统计" »

前几天我给几个做开发的朋友发了个消息，请他们帮我再次在Google Reader中共享了一篇旧招聘启事，可能他们的Gtalk好友都在Google Reader中看到了。
一篇文章在Google Reader中的确有过时很快的现象，超过1天后可能就被一片被淹没到数百篇未读文章列表后面了。而被好友较多的Blogger分享的时候还会带来一些新的阅读和传播机会；所以Google Reader的好友推荐是这个新的传播渠道已经被很多人运用的很好了，因为大部分人还不知道如何退订Gtalk好友的分享（难道要删除好友？） 也有很多朋友（ 比如Fenng）采取在发表文章几天后自我推荐的方法再次“提醒”自己的好友。

Google Reader的LifeStream机制:
其实Google真的没有必要收购digg的： Google Reader中的共享（收藏可以看作是匿名digg）已经是一个很好的内容推荐来源；
和DIGG相比： 缺少的是一个加注释/评论功能和一个频道聚合首页；
Google Reader更容易和GTalk组合起来的，如果有个给”XXX分享“：在线回复的接口可以增加更多交互和反馈；

按此阅读全文 "Google Reader的好友推荐分享： Blog内容缓释" »

在博客大巴最近的机房续约，机房搬迁和CDN的协议中，都遇到了下服务有效性条款的服务级别协议(Service Level Agreement, SLA)问题。在之前的很多服务合同中，国内的IDC大多是这样定义的： 服务中断1个小时，赔偿2倍时间的服务。这样计算：一个月下来如果网络陆陆续续中断了15天，才赔一个月的服务？ 比较一下国外相应服务的条款：
Nirvanix的SLA条款
Amazon S3服务的SLA条款

服务有效时间百分比每自然月 下月服务补偿百分比
大于等于99%同时小于99.9% 10%
低于99% 25%

另外一个问题就是监控的依据：
无论是基于服务商还是基于客户自身，都有一定问题。国内也不知道哪里有比较低成本的监控服务，而监控的细节就更成问题了，还有基于南北电信/网通部署不同的监控点等问题。

更新：2008-08-29
经过1个月的整理，机房的监控主要需要2个方面，即时统计和详细截取；
1 即时监控：主要的目的是用于确定事故的起始点和报警，这方面我们参考了山寨科学家的叽歪监控, 配合Nagios的E-Mail alert发送到手机邮箱报警，时间可以精确到2分钟，这时候Nagios的Cacti统计也有助于从宏观发现事故的特点和原因；
2 细节截取：出现问题的时候，还需要一个详细的事故数据，需要分析当时各个地区的ping tracerout情况等，结合基调网络的多点统计报表，这类统计成本较高，对即时性要求可以低一些；

按此阅读全文 "[咨询] 如何签署网络服务有效性条款SLA 服务监控网站搜集" »

上周末在博客大巴邀请了上海几家StartUp公司的朋友做了一次技术交流：VeryCD的科学家们，客齐集，联络家，CDNUnion，安居客和Sun的Startup解决方案专家；

主题1：动态内容的CDN缓存
结论，目前CDN缓存仍然以静态内容为主，动态页面缓存过期/更新策略较复杂；而CDN有purge接口，但现在实际应用较少： 更多缓存服务是为内容永不更新的图片、视频等服务；此外，固态盘代替逐步内存的可能性近期还没有，固态硬盘的仍然价格非常高，I/O的速度也是问题；

主题2： Memcached的使用
所有网站都用了Memcached，并通过避免对数据库的连接而大大提高了性能（命中率一般在90%以上）；

关于：多memcached的分布策略；
客齐集
规模： 在多台前端应用服务器上划出一定空间，
分布规则：使用的是memcached addserver方式由memcache自己进行缓存分布；
单点失败处理：遇到个别节点中断会retry；
博客大巴和VeryCD应用类似：
规模： 几十G（单个2G）；
分布规则：都是自己应用设置设置缓存分布规则，对数据进行分布，
单点失败处理：如果遇到Memcached中断并不尝试其他服务器；

关于memcache的压缩：
PHP客户端可以设置压缩外， server端也有更详细的压缩配置选项（memcached的文档中有？）；
关于memcached的扩展性： 最新版本有考虑consistent hash（在扩展服务节点后，旧内容仍然再旧服务器上，不用按重新按新的分布规则生成新缓存）
memcached： bin模式存储；

对于缓存对象：大的List列表页对象用memcache缓存对效率提升很重要；

主题3： Start up公司的招聘来源
客齐集的校园招聘成果还是让其他公司非常的眼红，另外说一句： 我们仍然在招前端应用开发人员（欢迎应届生）：有优秀的开发人员，各个Startup公司之间都是可以推荐的（VeryCD的51job招聘广告就是托管在博客大巴的），以后还会不定期做一些交流。

按此阅读全文 "山寨技术交流会： 博客大巴 / VeryCD / 客齐集 / 联络家 / CDNUnion" »

“我不是塑料袋”是一个很有趣的设计创意： I'm not a plastic bag

此次我不是塑料袋：环保袋设计大赛活动的奖品为：
评委会奖(1名)：MacBook Air + 5000元现金
( 歌手Yael Naim的那首《New Soul》你每天在电梯中都会听到多次吧？ )
独树一帜奖(2名)：价值5000元以上的尼康D60单反相机1台 + 5000元现金
不拘一格奖(2名)：价值2000元以上的多普达S1手机1台 + 5000元现金

* 奖品涉及到的个人所得税由获奖人自理
* 所有参加投票的网友均有机会抽取100名参与奖： BlogBus明信片一套*50套 触动传媒提供小礼品*50个

按此阅读全文 "[AD] “我不是一个塑料袋” 博客大巴环保袋设计大赛 一等奖为MacBook Air + 5000￥" »

尝试：
启用了PHP memcache_set()函数中的 MEMCACHE_COMPRESSED压缩选项，而memcache_get()可以在后续读取过程中自动对压缩的缓存对象进行解压缩。

效果：
测试了一下，对于博客大巴目前的应用来说，启用压缩后，相同的容量（2G）存储的对象数量增加了约一倍，缓存命中率从50%左右，提高到了60%左右。进一步提高命中率硬件投入还是必须的，又增加了2倍的内存后终于做到了缓存命中率提高到90%；

前提0： 内存缓存有用，且命中率值得提升；
从60%提高到90%，还是从90%提高到95%，要看hit后的性能能够提升是否值得；

前提1：MemCached已经用满
先用memcached-tool查看一下memcached的容量统计，看memcached是不是已经用满了。如果充分运行时MemCached的空间尚未用满，启用一下压缩是没有意义的； 而且：发现没有用满的MemCached，最好减少相应MemCached的容量，空余出更多内存给其他服务做缓存；

前提2： 压缩率
缓存的数据的确有大于几百字节的，如果都是小于100字节的键值对，压缩可能反而带来膨胀。由于缓存对象的大小在Memcached中都是按照固定大小分块存储的，最小也要88 B。所以对于过小数据带来的压缩膨胀并不是太大的问题；

前台应用的CPU损耗：
对数据的额外压缩CPU损耗远远低于缓存命中率提升减少后台数据库访问带来的性能提升，和http的gzip/deflate压缩类似，压缩后数据一般为原数据大小的30%左右，节省了70%的传输性能消耗所得会大于文件压缩带来的性能损耗；

按此阅读全文 "启用MEMCACHE_COMPRESSED压缩，“扩容”MemCached" »