Tin’s Blog

InfoQ上面的一篇文章《构建的可伸缩性和达到的性能：一个虚拟座谈会》
http://www.infoq.com/cn/articles/scalability-panel
这篇文章很好，给了你很多做可伸缩性的线索，记录下这些点滴。推荐感兴趣的人去InfoQ阅读原文。

ab & httperf: 它给我们提供了一些自动化的负载测试，因此对比于我们从firebug中获得页面级的计时，使用这个工具可以获得会话级的计时。
firebug:
Ganglia是非常优秀的。同时Nagios或Zabbix（举个例子）将告诉你何时资料遭到破坏，使用少量加工你就能够让ganglia给你提供任何东西。
对于MySQL，Innotop + slow query log 帮了大忙
GDB和DTrace是用于C++的基础架构。core或 pstack是个颇有价值的工具
我们使用各种工具来重现问题并调试它们（包括栈的问题）——Visual Studio、 Eclipse、WinDbg、cdb、Purify、Fortify、dtrace以及许多定制的东西，为我们的架构所构建的东西
从某点上讲，伸缩性已经从领域问题（即，如果你不使用内存缓存或者一个等价的分布式哈希表和基于内存的缓存）转移了，而你仍然处于“领域”范围
当今静态内容的可伸缩性已不那么重要了，那只是花钱的问题并需要公司有好的社会组织的问题
不要试图在部署之前就捕获性能问题。你不可能重建真实环境中的条件，因此你不可能得到真实可靠的测量结果
监测。非常仔细的监测
墨菲法则（一种幽默的规则，它认为任何可能出错的事终将出错）确保了你没有严密跟踪的衡量标准就是那个对你不利的标准！
除非你知道当时正在执行什么业务功能，否则一个CPU测量是无意义的
你只能通过使用软件实现伸缩性。“语言是不能伸缩的。框架是不能伸缩的。而架构是可以伸缩的。”

中午徐X和米高讲了一下Rich client的架构。其中徐X讲的是如何从单机分层系统到Rich client。
实际上最早的单机分层系统的UI部分激发了OO作为界面的编程模型。然后分层模型为了C/S结构发生了一些变化，目的是共享数据和通信，但是由于OO在远程调用上面的失败应用（Corba，EJB，Dcom），所以让人对OO产生了怀疑（实际上只是用错了地方）。而后又发生了B/S的变化，是一种完全的中心共享方式，原因是HTTP的无状态性造成客户端很难保存state，所以就有了完全中心共享状态的架构。而后通过通讯的增强（Ajax），客户端的状态保持逻辑通过异步通信来增强，所以产生了更好的用户体验。但是对状态同步的进一步要求和对会话状态保持的进一步要求让Ajaxian了的应用还是有点难以承受，所以Rich client又回归了。当然回归的时候同时带来的还有新的编程模型，如基于标记的声明式编程模型，还有更方便View-Model同步（通知）的数据binding机制，布局管理器，绘图支持能力，多线程能力，内嵌的视频编解码能力。其实WPF作为Windows上的新型UI编程模型他的确从Mozzila的XUL还有Adobe的mxml吸取了一些经验。上面这些是徐X阐述的主要内容，很精彩（最后的编程模型是我加的注释）。
而后米高做了一些技术层面的对比，主要是对比了Web和rich client的区别，不过我比较失望^___^，因为对比有失偏颇，原因是米高只用了5分钟准备ppt。
最后是我的意见。我现在已经不想割裂的分开Rich client和Web上的RIA，实际上目前他们已经有走向统一模型的趋势。
去年在InfoQ写文章的时候我就表达过这个意见。今天徐X也强调了，经典的MVC实际上很重要的是解决了数据共享（同步通知问题）与状态（会话）保持的问题，所有的架构问题其实都围绕了这个问题。首先RIA里面已经开始了layout数据分离的加强过程，比较明显的就是声名式的组件组合配置，还有数据绑定模型，这个在Flash和Silverlight还有JavaFx都有着重的解决，而且方向都很类似。其中Silverlight其实是一个减缩版的WPF。然后我们从架构方面来思考，解决状态共享和传递是通过增强的双向通信能力来完成的，很多RIA框架在开始提供web socket模型，这样让通讯超过无状态的且单向的HTTP，包括HTML5（目的是扩展Web上常用的一些Object，增强Web的编程能力，且让很多元素得到正确的语义，这个与XHTML2的关注点不同）的草案里面也有Web socket（类似socket的编程对象，可以实现二进制协议的面向连接的通讯）的提案。当然些努力就是让实现消息传递的开销更小，时效性更高，配合线程概念的支持，就可以实现复杂的基于消息的异步界面逻辑（这会极大的扩展RIA应用的能力）。因为通讯其实是解决状态共享的一个方向，通过高效的消息通知达到多个消费端的状态共享。另外一种解决Browser端状态同步（这里主要指客户端与服务器的数据库同步）的方法就是离线存储能力，这样削弱客户端对服务器的依赖。这种解决方案的代表就是各种Gears，Google gears，dojo offline等等，他们在浏览器里面嵌入sql lite一类的数据库，让客户端有自己的结构化存储能力，对于没有多客户端数据同步要求的应用来说离线方式可以让客户端形成完整的编程模型，通过sync机制在连线的时候进行数据同步是一种非常帮的RIA发展方向，从这个角度它已经是Rich client了。
那么可以扩展一下。我们知道Lotus Notes有服务器端replication的模式，离线会存在本地，连线的时候再同步。而对于另一些应用，极端地如Skype，他对实时的同步要求很高（当然它属于通讯类应用，也就是3C中的Communicate，而不是Content system），Skype的解决方案就是p2p。如果RIA有了socket（当然还有跨域支持），有了多线程，那么p2p是不是也不算难事了呢？状态同步通过p2p来实现，虽然不是可靠的通讯方式，但是却符合Internet的最大努力原则，所以我觉得这两种技术的结合的确很容易让RIA和Rich client不在有明显的界限，未来的目的就是融合。所以，要注意的是为什么微软拼了命在推Silverlight，而且拼了命的公布了Mac和Linux版本的Silverlight，其重要原因就是让WPF的模型渗透到RIA，用Rich client围攻RIA，来解决Adobe用超级NB的Air这个RIA衍生来围攻Rich client的困难。
这样，我们知道2年前开始声音渐强的Offline storage和越来越强的绘图，data binding的意图了吧，融合已经开始了，目标当然就是吃下这个大平台，然后成为最大的赢家！

这个幻灯片是我为Beijing Open Party所准备的，好看簿也有图片版本。欢迎所有对网站可扩展架构感兴趣的朋友一同交流，也欢迎参加Beijing Open Party的活动。

| View | Upload your own

中文网志年会2007

跟大野狼、蚂蚁、二傻参加了今年的网志年会。这里记录下我的见闻。这不是一篇时效性很强的故事，但是看完以后你会回忆起网志年会的点点滴滴。

第一天最精彩的Session-第一天最精彩的Session 飞猪为反波做了一个Keynote。非常酷！Keynote比PPT更容易做出酷的东西。

[...]

简短说，因为重新在新mac上装mercurial，没有装macports也没有fink，这次也不想自己编，所以选择了预编译的package。但是后来发现报错！
我用的是http://mercurial.berkwood.com/这里的包，1.0.1的mercurial package，是08-05-25出的那个包。

line 373, in _parse_localename
raise ValueError, ‘unknown locale: %s’ % localename
ValueError: unknown locale: UTF-8

那么，如何解决呢？这里找到了答案：
http://www.selenic.com/pipermail/mercurial/2007-October/015296.html
解决的方法就是在你的.profile加入下面这样的声明，如果你用的是bash的话。

export LC_ALL=es_ES.UTF-8
export LANG=es_ES.UTF-8

然后就工作正常了，如果想知道为什么，可以看看这里有更详细的原理介绍，LC_ALL是给字体字符集使用的环境变量。
http://www.madboa.com/geek/utf8/
结绳记事，希望有帮助。

因为懒惰，所以一直没有解决一个问题。我的苹果一直不能访问家里的台式机，但是家里的台式机实际上是我家的文件中心，在已经卸下两块硬盘的情况下，这台机器上还有320X2+250+120=1010G的硬盘空间。我从用笔记本看电影的时候希望可以访问Windows的共享目录，但是却每次都提示您没有权限访问文件共享。可是我已经为苹果设好特别的帐号了，非常费解。但是在苹果上访问别的Windows电脑却正常。
百思不得其解，但是最终还是解决了。不废话，说方法，我的是Windows XP SP2：
1、去Windows上，在我的电脑的工具-设置里面，取消“使用简单文件共享（推荐）”这个选项。
2、这个时候再去共享目录或者驱动器根的时候你就可以选择帐户和连接数了。选择你要使用的帐户，加入到授权访问的帐户列表中去，即使里面已经有Everyone了。
3、去苹果上在浏览器（如Safari）里面输入smb:\\192.168.1.x，或者直接在Finder里面选择相应的主机名。这个时候会询问你帐号和密码，然后输入你在Windows上面的帐号就可以了。
怀疑原因是我的Windows正好出了什么毛病，我的新帐户可能也许不在Everyone里面，虽然不应该，但是不管它了，你完全可以将目录的访问授权只给特定的用户，如我的电脑上有个mac用户，使用密码保护，这样可能更加明确。
那么，反正这次的麻烦就归在倒霉的“简单文件共享”上免了，它一点也不简单！

这两天收拾硬盘，发现以前的分区方式已经不能满足我了。
此时，我已经有120G x 3，和80G x 1了，再加上单位暂借的160G，组成比较大的硬盘阵营了，不过显然过气了。还好我有Promise Ultra 100的IDE卡，否则虽然总容量不算大，但是硬盘量可不少了。
原先的120G分别有5、4、3个分区，而新的160G则只有1个分区。现在的数据有很多ISO，容量巨大，再加上Mp3的爆炸，多个小分区不好用了，所以这两天花了不少时间整理这些硬盘，把该合并整理的都处理了。
然后就是腾空、重新分区，我对PQ的PargitionMagic有心理阴影，不要推荐这类软件给我。整理的成果让我很满足，我渐渐变得有条理了，紊乱会被消灭的。
瓦卡卡！

发现MSN Spaces升级了，满好玩的，不过好像是有Bug的，目前带着自己的信息给别人留言还有问题。
如何提高效率呢？
1、最好要有一个可以移动的工作平台。或者自己总结一个回复工作平台的步骤。自己经常对自己所做的事情做记录，并分享。
2、关于信息的获取，除了使用搜索引擎，还可以考虑订阅RSS。通过FeedDeamon这样的Rss阅读器，可以定义自己的频道，在里面收藏关注的站点（尤其是技术Blog），如此通过适时的跟踪，可以保证信息获取的及时。
3、使用一个文章收藏工具，如CyberArticle（网文快捕）。通过它的分类收藏功能，可以将自己关注或者有用的技术文章保存下来，并且可以方便的制作电子书。它的最大优点是可以将你所有的技术文章（网页）保存为一个统一的book文件，方便管理和备份。
4、掌握一个拿手的编辑器。用Windows的朋友可能习惯使用NotePad（记事本），但是它并不怎么好用。推荐习惯UltraEdit或者EditPlus这样的强大的编辑器的功能，使用批量替换，字符显示，文件编码等问题的解决（如果感兴趣，用UltraEdit的16进制编辑功能可以帮你发现更多的隐藏的编码问题）。我偏好EditPlus……
5、这个年代要掌握eMule和BT的基本使用方法。BT对于获得流行的资源非常有帮助，而eMule则对获得非流行的资源（如eBook、冷门mp3等）非常重要。注意不少eMule Client有积分，注意积攒，对排队有效。
6、如果你还没有Blog，最好有一个，可以催促你积累和共享你的收获。

祝大家新春快乐，狗年吉祥！

晚上跟zh等同志一起看了下文件下载的中文问题，问题解决，并且收获不小：1、java的char类型是16bit，而不是c/c++中的8bit，所以char和byte之间的转换会造成严重的精度损失。而Java的char是Unicode的。2、java中String是基于char[]的，也就是说这个String天生就可以表示Unicode。所以如果从byte[]创建一个String就会涉及到一个严重的策略问题，是一个byte转一个String字还是两个byte转一个String字。3、所以我们常用的java转码中的语句somestr = new String(somestr.getBytes(),"ISO-8859-1")与somestr = new String(somestr.getBytes(),"GB2312")之间是有很大区别的，它们关系到从一个byte变两个byte或反过来。4、所以，对于单精度的"ISO-8859-1"与双精度的GB2312、GBK、utf-8处理的时候一定要分清，而且它也可以解决很多的问题。而如果你好好了解GB2312与GBK的效果其实很类似，他们只有部分的编码覆盖度上的区别，大部分字符是通用的，可是"ISO-8859-1"却与他们完全不同。5、还有一个有意思的地方：java.io.Writer与java.io.InputStream下面的东西有个明显的区别，前者接受char[]，而后者接受byte[]。其实理解一下，他们之间的转换其实正好需要String的单字节编码与双字节编码的区别，我们可以用它们完成有意思的转换。在它们的沟通过程中我们如果使用buffer，则需要String作为中间者进行转换，算个小trick吧。6、从这里，我们引出今天解决的中文文件下载的问题中的有意思的地方：<%@ page language="java" import="java.io.PrintWriter"%><%String filename = (String)request.getAttribute("downloadFileName");String filepath = (String)request.getAttribute("downloadFileUrl");

filename = new String(filename.getBytes(),"ISO-8859-1");if(filename != null && filepath != null) {response.setContentType("APPLICATION/OCTET-STREAM");response.setHeader("Content-Disposition","attachment; filename=\"" + filename + "\"");java.io.FileInputStream fileInputStream =new java.io.FileInputStream(filepath);

java.io.File file = new java.io.File(filepath);response.setContentLength((new Long(file.length()).intValue()));PrintWriter pw = response.getWriter();byte[] charArray = new byte[4096];int len;while ((len=fileInputStream.read(charArray)) != -1) { String s = new String(charArray,"ISO-8859-1"); pw.write(s);}pw.flush();pw.close();fileInputStream.close();}%>

今天，又看了下上面这个例子里面的starter那个例子，发现： 它使用了Spring的自动装配，以下两段代码效果相同： java代码: 

<beans default-autowire="autodetect">         <bean id="personManager" class="com.acme.PersonManager"/> </beans>

java代码: 

<beans>         <bean id="personManager" class="com.acme.PersonManager"/>         <bean id="listPeople" class="com.acme.ListPeople">                 <property name="personManager" >                         <ref local="personManager" />                 </property>         </bean>         <bean id="createPserson" class="com.acme.CreatePerson">                 <property name="personManager">                         <ref local="personManager" />                 </property>         </bean> </beans>

如果这样使用的话，如果在xwork里面配制好action的class，然后连这个class的bean都不用在spring里面声明了，其依赖也通过名字匹配自动装配了。 真简单啊，想知道spring的autowire有没有性能损耗，如果每次装配都反射会不会性能很差？