手机又丢了

    昨天出去玩，拉小黄出来溜冰，结果被还了一个电脑。我还要买一个键盘给别人，手上一堆东西，再打车去见人。时间紧，手上大包小包一大堆，下车的时候两手满满的。下车了再一拍兜——杯具啊～～～～手机丢了。
    估计是放兜里面没放的太进去，于是联系去找。大众的调度��嗦嗦的，问你上车时间下车时间车号前后排什么的，问了一堆。我当时心就一凉。司机每天要开车的，总算还比乘客靠谱点。下一个乘客上来，那可就彻底讲不清了。要验证我的身份，大可以等东西找到再说。估计这堆罗嗦问题就是要等到说下个乘客可以上车，然后再推说可能是乘客问题，让你无话可说的。所以大家车上丢了东西，就别指望调度了。
    消息回来，果然找不到，手机满电的，也关机了。于是只有紧急停机，外加修改了所有在上面涉及过的密码，包括我的QQ，MSN/Hotmail，Gtalk/Gmail，还有张老师的blog。这里普及一个常识，手机使用的时候，一定要将手机设定为和SIM卡绑定。然后在手机丢了以后，立刻停机。这样做的主要目的是防止手机诈骗，例如打给你朋友，说你车祸了在急救，这里是医院，赶紧汇钱到XX账户啥的。我的朋友一般还比较懂行，肯定会挂了拨我号码以验证是否是我本人——问题是，那还是打到他手机上啊。人家和你够铁够仗义才付钱，万一被骗了，你好意思不赔他损失么？所以，丢了一定要停机。而SIM卡绑定，对于专业人士来说不难解，而对于业余人士则不好解。如果是外行捡到，卖给玩手机的就要被宰一刀，所以最好的思路是打上面几个人的电话问问要不要把手机买回去什么的。如果手机没绑定，大多都是拿到就用了，这个选项根本不可能。至于记录IMEI号什么的——你还没那个面子让移动封掉这个手机。另外上面如果用过QQMSN什么的，也赶紧改密码。不要心存侥幸，一天也许没事，两三天万一他解锁出来了，你哭都来不及。
    至于数据么，大部分都有备份，但是所有人的联系方式肯定都泄密了。大家如果看到其他人，用别人的手机，宣称我如何如何的——别信他。半年内的联系人可能需要重新添加，回头我会一一联系。
    至于其他么，半年内和我发过短信的，你们的短信都曝光了。和我照过相的，你们的照片都曝光了(这可不限半年，实际上我刚买的时候照的都还在)。其他数据应该没什么风险了，以上。

    以下不算钱:
    啊～～～～我的手机啊，又要买新的了，怨念。

一个远程下载verycd的小技巧

    贝壳家里开了emule，天天下载，问题是又不能每次都是晚上添加资源。
    怎么办呢？不知道大家知道不知道，emule是可以网络管理的，端口是4711。不过不是https，密码容易泄露。而且贝壳已经有一个nginx服务器了，也懒的再做端口映射，换端口。于是，在nginx中做如下设定。(当然，贝壳是放在https段中的)

location ^~ /emule/ {
    rewrite             ^/emule/(.*)$ /$1 break;
    proxy_pass          http://hostip:4711;
    proxy_set_header    Host            $host;
    proxy_set_header    X-Real-IP       $remote_addr;
    proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
}

    然后，用https://dynname/emule/就可以访问你家里的emule了，记得密码设强点。

    接下来，verycd里面曾经有复制所有连接的选项，现在没了。面对几个链接，也就手工复制一下，面对上百个连接，贝壳就无语了。贝壳试验过几个插件，都无法正确识别ed2k的链接获取。那怎么办呢？这时就要请出我们伟大的Linux。
    需要准备的工具是lynx，请预先装好，然后如下操作。(范例是个动画^_^)

wget -c http://www.verycd.com/topics/2779234/
lynx -dump -listonly index.html | grep "ed2k://" | sed "s/.*ed2k/ed2k/g" | grep -v BIG5 > out.txt
wc -l out.txt

    lynx的-dump选项是将某个网页全部渲染成文本进行展示，这是html2text的好方法，效果还不错哦，不过中文支持好像不是很好。而-listonly则是展示出页面上的所有链接，这就拿到了我们需要的原始数据。
    然后，我们取其中的ed2k行，忽略其他链接，再通过sed转换，去除头部的编号和空格，这样就可以得到所有的ed2k链接。
    我在下面是用-v BIG5的参数，忽略了其中繁体中文的资源，然后输出到一个文件中。数数行数，52行，大致和文件个数相当(其中好像有两个v2)。那就是可用资源了，复制到emule的控制页面中——出错？
    这是因为emule的控制页面使用GET方式传递参数，因此有长度限制。你需要将链接10个一批往里面复制——有个几次就OK了。当然，如果还是多，贝壳回头会写一篇文章，介绍如何使用curl自动干这事情——这还不算太难。
    这就是为啥贝壳喜欢Linux的原因了。相比Windows下的两个解决方案，找插件太费劲，自己写程序更费劲。Linux使用现有工具的组合可以轻松完成这一任务。

关于减少使用gmail的建议

    这次，google又不走了。
    事情处于很奇怪的状态，google本是不可能留下的。既然它留下了，我们说，事有反常必为妖。这次妖在哪里呢？
    我建议大家减少使用gmail，最好别用。原因如下：
    如果google的却是受到了某些关于知识产权的攻击，但是却愿意在中国留下，并且在发生这次的事件后，还能留下。这说明google(非中国的谷歌公司)已经和北京达成了某种秘密的和解协议。无论这个协议的细节是什么，我们有理由猜测，google的产品不能完全的信任了，包括gmail，google reader，bloger等。
    另一方面，如果google并没有受到这些攻击，那就是出于各种原因的新闻炒作。既然google背弃不作恶的宣言在前，那杯葛在后也是自然而然咯？
    所以说，如果google打算继续在中国留下，那么包括gmail在内的各种google产品，都必须视为非安全产品看待。建议尽量减少使用，并准备替代方案。

关于海地地震

    深切同情这种虚伪的话就不说了，我们又没被震过，装B只会遭雷劈。
    我得说，海地人民，海地政府还是比较公平的。学校倒了，总统府也倒了，这两天净看到倒塌的总统府了。在神奇的土地上，只听说学校倒塌压死人，还没听说政府机关房子倒塌压死人的情况——那到真是造福全社会了。

关于google退出中国的FAQ

F:google真的准备退出中国了么？
Q:历史告诉我们，两个人谈价的时候，如果出现有人生气要走，那可能是讲价的手段。如果出现扇耳光，那么多数是谈崩了。除非被扇的人授意这么做，否则双方都没有回头路可走。目前google等于明确的在指责中国进行网络监控，并试图进行网络攻击。耳光都扇出去了，下面就不是谈价的问题了。

F:中国政府会怎样处理google的谈判呢？
Q:这也是个挺头痛的问题，要是让google就这么走了，无异于变相承认了中国的网络舆论监控和网络安全问题。但是要答应无控制的搜索，那是绝对不可能 的。可能会派出发炎人，声明，中国要求google进行网络控制的理由是为了防止网络色情和网络暴力，这是我国内政，其他国家无权干涉。目前没有证据表明 入侵google的黑客得到中国政府的授意，任何试图联系两者的人都是邪恶和别有企图的。中国是一个开放的市场，任何人进入和离开是个人自己的选择，中国 依旧欢迎其他公司来中国建厂投资。

F:google退出中国真的是因为不作恶么？还是为求一个体面的退出？
Q:别太把自己当回事了。google在中国的利润有多少？不超过总利润的10%。投资有多少？鬼知道。市场份额多少？33%。我们不看其他，就算中国市场全争取过来，最高也只能将利润增加到25%((10*3)/(100+10*2))。也就是说，中国最多是一块肉丝，而美国是块肥肉。如果肉丝真的有臭掉的风险，宁可丢块肉丝，也别丢肥肉。
而且，一旦明确指责网络舆论控制和网络安全问题，那么，同样进入中国的其他大型厂商就会陷入被动，包括微软，雅虎等。撤吧，他们的市场份额更大，问题也更复杂。不撤吧，他们在美国的形象会受到影响，有利于google在其他地区的业务。

F:google走了，百度得益了？
Q:短期来看，没错，长期来看，市场会重新平衡。由于百度在谈判上的强势地位，因此会导致代理商和广告主非常难做，同时互联网广告的成本会增加。进而加剧劣币驱逐良币，最后让整个互联网的所有广告都变成近乎于废纸，互联网广告业务名存实亡。
而且，一旦google离开，百度就会直面政府。从政府需要"团结和依靠"的多数，变成需要"警惕"的"怀有异心"的人。可以预见，政府对百度的监控和利用会达到一个新的高峰(因为用不着让你活着对付google了)，并且可能会提出注资成为某部下属机构的要求。

F:google走了，我们将会怎样？
Q:google的离开，标志着中国的互联网整体倒退了6年。在IT界，3年是一个时代，6年的倒退，让我们退回了两个时代去，变成了上个世纪网络刚刚兴起的时候，那种上网艰难的状况。这不是用备份邮箱，备份新闻标签等方法可以解决的。
更严重的是，这会严重打击整个业界，工程师，对于中国的网络发展的评价。在这个问题解决前，我们可能落后其他国家10年以上。当然，之所以我这么担忧，其实还是因为这直接影响到了我的饭碗。

手工删除oracle数据库实例的全部文件

    今天公司搬家，没啥好写的，简单记录一下前两天删除重建oracle数据库的过程吧。
    首先，我重建的是oracle数据库，而不是oracle数据库程序。这几天不知道怎么回事，整个数据库的redo log出问题了，我又懒得去找。加上这个数据库做演示的时候乱糟糟的配置做了一堆，也记不请了，干脆重建。
    重建的第一步，需要找到所有程序实例的位置，这个可以看/etc/oraInv什么的一个文件，这里会指向一个目录。这个目录是标准的，里面有各种格式的oracle程序实例的位置。然后，一个程序实例可以运行多个数据库实例，因此，要找出这些数据库实例的配置文件。这个就需要对oracle的数据库基本结构有所了解，这里不赘述oracle数据库的各种基本概念。
    oracle的数据库配置文件在一个很怪的位置，/etc/oratab里面。其中有SID到spfile路径的对应关系，通常而言，这个路径位于$ORACLE_HOME/dbs/init$ORACLE_SID。我们首先不要删除这个对应关系和文件，因为启动中其他文件需要通过这个找到。我们首先通过spfile建立pfile，来读取其中的参数。
$ export SID=orcl
$ sqlplus / as sysdba
> create pfile from spfile
> exit
    OK，这样我们就建立了pfile，现在可以删除$ORACLE_HOME/dbs目录下所有的SID相关的文件，并且删除oratab中的对应关系。完成这步后，数据库就无法启动，也不存在了。但是我们还需要回首数据库相关的文件，主要是收回空间，同时也免除后患。
    首先，数据库有三个control files，还有一个到多个data files，以及多个redo log。在默认设置中，这些文件一般放在一起，你可以通过查看pfile确认这些文件的路径。找到之后，直接删除，没啥好多说的。在完成数据基础文件的删除后，我们还需要删除flash_recovery文件，这个也可以通过pfile确认，位置一般在data文件上两级(就是通常$ORACLE_BASE的位置)下面，flash什么的一个目录，很好找。
    最后，我们删除admin目录，具体是在$ORACLE_BASE下面的admin下面，以SID命名的，可以通过pfile确认。至此，oracle数据库的删除完成。不过呢——呵呵——让大家失望的是，其实DBCA也可以完成一样的工作...
    不过，dbca的工作必须通过vnc，绝对不要通过ssh + xming，因为那个会让最后一步执行前的确认无法被确认，导致不能执行。实在是很让人郁闷的一个bug，切记切记。

replay

发现最近的生活，越来越重复了。怎么说呢？每天早上起来，照例刷牙洗脸，吃饭出门。走在南泉路上，会看到一辆119。拐到兰村路上，会看到一个黑衣MM，对面走过来。人很漂亮，一般是在打手机，否则就是拿手机听歌。前走一点，有个保安在和卖煎饼的聊天，一个抽烟一个翻煎饼，每天的差异差不多就是有客户和没客户而已。再往前，在东方路前会碰到一个辫子MM走出来，辫子很长，从后面看很漂亮。不过记住，如果你不想对世界失去信心，一定要走在她后面。走在前面千万不要回头，无论是有人喊你还是后面有车要70码你。我头次很好奇的回了个头，结果一天都无法正常工作。走到东方路，有八成概率是一堆人在等红灯。恭喜，这代表你会在20秒内碰到绿灯――平均值通常是5秒。

上地铁后就更规律了，如果一堆人在等车，那车上肯定也是一堆人，你如果被挤上去就算是走运了。相反，如果只有小猫两三只，那么车上多半也没有人，慢慢走上去就好。到了世纪大道换车，就可以开电脑放音乐，头一首歌照例是《钢之炼金术士2009》的片头。到了张江，有车停左边和车停右边两个选项。不过没有关系，凡是在进站前停车的，就是左边，否则是右边。因为车要靠右开，停靠右边站台的车在开出时，换到左边(相对他是右边)，而我们的车在进站时要靠左，也需要换边。不停车怕又碰到昨天一号线的事故，因此惯例是要停车的。

地铁下来后，有两个红绿灯，第一个灯是20秒横走40秒直行，因此多数会直行过去。第二个灯是50秒横走20秒直行，因此多数会横向过街。联合以上数据计算概率，两次直行的概率是19%，先直行后过街的概率是47.6%，先横后直行的概率是33.3%。没有觉得什么不对？看来又多一个走傻掉的。计算以上概率的方法是分支法，联合概率乘法？我没事先过个街，第二个路口走回来？那不真傻了？

最后，到办公室。一般这时候是王菲在唱《只有我自己》。如果刚唱到"走过千山万水"，那说明地铁走的还是挺快的。如果已经到了"失去你，就失去，面对孤独的勇气"，那――要么是地铁走的慢了，要么是你走的慢了。

论BTchina的倒掉

    BTchina倒了，死的很惨。被广电总局直接勒令关闭，连整改的机会都没有。无疑，大家都知道，VeryCD会紧随其后。无论是非如何，请允许我先向这两家陪伴我多年的网站道声感谢，一路走好。

    就打击这个问题来说，我无疑是赞成的。广电总局打击集中向两个关键词，盗版和非法。无论哪个，都是应该打击的对象。但是这次打击本身却值得怀疑，主要集中在三点，是否允许整改，选择性执法，还有实际效果。

    首先，拿整改问题来说。BTchina和VeryCD做的是下载业务，其中有盗版下载再正常不过。一般打击都是先责令整改，然后再关服务器——虽然我们知道责令也不见什么效果，BTchina肯定改不过来的。不过样子还得做啊。不过从某种意义上说，样子做不做也就是政府内部的事情。无论做不做都是合理合法的，所以这点问题还不大。

    其次，我质疑比较大的一点，就是选择性执法。有个朋友说的比较精辟，每只猫都有他的目的。我总是不惮以最大的恶意来揣测咱们的政府——他们这回想干啥？如果要打击盗版，那问题严重了去了。中国桌面上，十有八九都是盗版Windows。哪怕你买了个笔记本，上面带了个正版Vista，一般也非要装个番茄花园不可。中国人看的电影，听的歌，乃至于用的手机，都是盗版产品。所以从这个角度说，我到真的很愿意国家打击盗版。盗版没了我们的软件才更好卖，盗版没了才有人被逼用Linux，盗版没了我们这行才能赚钱。不过咱得看事实，不能听风就是雨，更不能YY。广电总局要真有决心打击盗版，首先应该奔着卖盗版盘和卖盗版书的去——虽然他们也被互联网下载整的生不如死。问题是，他们没有。

    那，会不会是打击非法音像呢？这话说的更搞笑了。BTchina和VeryCD上有没有色情我不敢说，不过要有也绝对少于新华网。这不是指责新华网有多色情，而是阐述两者身为不同主体的无奈事实。BTchina和VeryCD要是碰到色情门那是沾上就死抡上就亡。作为半国企的新华网，就算偶尔行为出格，只要不出大差错无非就是检讨一下而已。这种情况下，前两家的审查力度，和后一家怎么可能同日而语？实话说，我当初还非常努力的试图在VeryCD上找什么色情资料。只能说他们的版主比较尽责，连疑似的都没有。要打击非法音像，还得找小网站——就是那种准备烧一把就走的。除非碰上严打，否则等查处来的时候，人都没了。

    那我就得怀疑了，广电总局想干啥呢？说打击盗版，不像，说打击非法音像，也不像。这事情我怎么看怎么觉得像上海政府查处黑车，黑车不黑车不重要，重要的是规范正当市场——说白了就是交钱。百度百科也涉嫌抄袭Wikipedia啊，怎么没看广电局找他们麻烦呢？人家3000万春晚赞助可不是白交的。

    那这事靠不靠谱呢？我只能说，越来越不靠谱了。从本心来说，我希望打击盗版，但是从现实而言，无论是美国政府，欧洲诸国政府，还是中国政府，对打击盗版都没啥办法。前两者有海盗党——当然，他们也被人盗版了他们的logo，真是讽刺。后者则有1亿多网民，每天发明各种奇怪的办法。现在的网民水准是越来越高了，或者说软件是越来越傻瓜了。原来下载必须在中心节点上投入大量资金，而且政府一来就玩完了。后来则是中心节点上只要搭个论坛，剩下的自然有P2P软件搞定。现在，根本就没中心节点。DHT的普及，使得去中心化的优势体现的淋漓尽致。Emule里面可以用kad搜索，直接搜索你需要的资源——正常情况下不比VeryCD差。而torrent里面则有个种子市场，可以直接搜索你要的种子。

    好家伙，连服务器都不要了，这次广电局再要下手，只有从网络传输上下手了——中国为了解决轮子问题，为GFW投资了不少钱。不知道广电局是否能收到足够的钱，把这个系统扩大个几倍，把P2P的混淆协议也全概括进去。作为一个老程序员，我劝诫所有的下载者一点。下次再弄的时候，用emule的kad搜索来找你需要的资源，你会发现其实verycd也不是必须的——虽然对他们来说，这是个比广电局查处更不利的消息。

用python实现webserver(二)――Thread

    我们上面说过，Prefork模式有着先天的缺陷。针对http这种大量短请求的应用(当然，http1.1以来，有不少客户端使用了长连接)，Prefork的最高并发很让人不满。并且，无论是否高并发，Prefork的性能都非常不好。现在我们介绍一下Thread模式。
    和Prefork非常类似，每Thread模式通过新建的线程来控制对象的传输。和Prefork模式不同的是，一个用户能够建立多少个线程并没有限制。在系统上似乎有限制，65535个，但是同样，文件句柄最高也就能打开65535个，因此通常而言一个服务器最高也就能顶50000并发，无法再高了(nginx就能够支撑5W并发，再高要使用一些特殊手法来均衡负载)。而且线程的建立和销毁的开销非常小——没有独立的空间，不用复制句柄，只要复制一份栈和上下文对象就可以。但是，由于所有线程运行在同一个进程空间中，因此每线程模式有几个非常麻烦的瓶颈。
    首先是对象锁定和同步，在每进程模式中，由于进程空间独立，因此一个对象被两个进程使用的时候，他们使用了两个完全不同的对象。而线程模式下，他们访问的是同一个对象。如果两个线程需要进行排他性访问，就必须使用锁，或者其他线程同步工具来进行线程同步。其次，由于使用同一个进程空间，因此一旦有一个连接处理的时候发生错误，整个程序就会崩溃。对于这一问题，可以通过watchdog方式来进行部分规避。原理是通过一个父进程启动子进程，子进程使用每线程处理请求。如果子进程崩溃，父进程的wait就会返回结果。此时父进程重启子进程。使用了watchdog后，服务不会中断，但是程序崩溃时正在处理的连接会全部丢失。最后，是python特有的问题——GIL。由于GIL的存在，因此无论多少线程，实际上只有一个线程可以处理请求，这无形中降低了效率。下面我们看一下Thread模式的测试结果：
测试指令： ab -n 1000 -c 100 http://localhost:8000/py-web-server
返回结果：
Document Path:          /py-web-server
Document Length:        1682 bytes

Concurrency Level:      100
Time taken for tests:   3.834 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      1723000 bytes
HTML transferred:       1682000 bytes
Requests per second:    260.85 [#/sec] (mean)
Time per request:       383.362 [ms] (mean)
Time per request:       3.834 [ms] (mean, across all concurrent requests)
Transfer rate:          438.91 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   75 468.4      0    3001
Processing:     2   32  84.0     20    1593
Waiting:        1   30  84.0     18    1592
Total:          2  107 511.0     20    3828

测试指令： ab -n 10000 -c 1000 http://localhost:8000/py-web-server
返回结果：
Document Path:          /py-web-server
Document Length:        1682 bytes

Concurrency Level:      1000
Time taken for tests:   37.510 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      17231723 bytes
HTML transferred:       16821682 bytes
Requests per second:    266.60 [#/sec] (mean)
Time per request:       3751.004 [ms] (mean)
Time per request:       3.751 [ms] (mean, across all concurrent requests)
Transfer rate:          448.62 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  695 2422.8      0   21004
Processing:     0   67 341.1     28    9855
Waiting:        0   64 340.5     26    9855
Total:          0  762 2516.6     29   30856

    根据结果可以看到，Thread模式在1000并发的时候还工作良好，每秒处理请求数在250-300req/sec，但是每个请求的总处理时间已经高达760ms。并且从中我们可以看出，大量的时间都是消耗在等待上，说明线程的建立逐渐成为问题(为什么？下面说明)。实际性能测试的结果，也表明大约一半的时间花费在了等待上，而另一半花费在了线程建立上。加上销毁的开销，整个系统主要的瓶颈在于由于大量线程建立和销毁造成的CPU开销上。
    结合上述情况，我们同时也想到一些问题，Thread模式在一个进程中，到底能创建多少个线程？上文上说大约是5W个，其实太理论了。实际上如果按照Windows来计算，最高不超过1000个，Linux下也在这个数量级上。为什么？由于进程内存空间的问题。一个线程在创建时，默认需要1M的内存空间来作为栈。对于专用的高速系统，我们建议将这个值调整到500K，一般一个session的内存消耗就在500K上下，考虑还有堆消耗，500K是一个比较安全的值。单一进程，32位访问的寻址空间是4G，然而系统需要使用其中的2G作为系统空间——这一状态可以经由启动时的3G参数调整(针对Windows)。然而由于使用了系统空间，因此系统中很多表项空间不足，对稳定性也有不利影响，通常我们建议不要进行这种“优化”。而系统的基础使用和库使用需要数百M的空间，安全起见，能够自由的用于栈的可分配自由空间只有1G的大小。这1G的空间，以创建1M的栈计算，只能同时开1000线程。这就是单一进程中线程的极限。
    实际上，是根本做不出这么多的线程的。贝壳的小型测试机上只观测到过10-20个线程/每进程。这是由于线程的建立也需要时间，在创建下一个线程之前，工作进程已经跑了一些了。创建几个工作线程后，第一个工作线程已经完成工作。因此我们在实际中看到的是，压力越高，连接建立的速度越慢。因为负责创立新线程的线程获得越少的CPU时间用于工作。为了增加处理速度，通常我们可以采取一个CPU建立一个进程的策略，这被称为多线程/多进程模式。下面我们来测量其工作效率：
测试指令： ab -n 10000 -c 1000 http://localhost:8000/
返回结果：
Document Path:          /
Document Length:        3318 bytes

Concurrency Level:      1000
Time taken for tests:   20.319 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      33590000 bytes
HTML transferred:       33180000 bytes
Requests per second:    492.14 [#/sec] (mean)
Time per request:       2031.939 [ms] (mean)
Time per request:       2.032 [ms] (mean, across all concurrent requests)
Transfer rate:          1614.36 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  160 912.4      0    9008
Processing:     0   28 174.7     12    4738
Waiting:        0   27 174.3     12    4738
Total:          0  188 987.5     13   12758

    这是台双核的机器，性能差不多提升了一倍，这就是多进程/多线程模式的威力。按照这个数据外推，在常见的8核处理器上，将达到2000req/sec的处理速度，甚至更高。
    当然，也不用高兴太早，我们看一下apache2的每线程模式：
测试指令： ab -n 10000 -c 1000 http://localhost:8000/
返回结果：
Concurrency Level:      1000
Time taken for tests:   6.147 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      3213925 bytes
HTML transferred:       453375 bytes
Requests per second:    1626.87 [#/sec] (mean)
Time per request:       614.678 [ms] (mean)
Time per request:       0.615 [ms] (mean, across all concurrent requests)
Transfer rate:          510.61 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  111 398.3     59    3087
Processing:    28  126  99.0    113    1772
Waiting:       10  104  98.7     92    1745
Total:         78  237 423.1    175    3691

Percentage of the requests served within a certain time (ms)
  50%    175
  66%    188
  75%    207
  80%    217
  90%    235
  95%    256
  98%   1016
  99%   3222
 100%   3691 (longest request)
    这种效率在8路的CPU上，性能将达到6400req/sec。所以想用python实现真正高效的前端本身就是个错误的逻辑。

MSN强制升级

    从前天开始，单位里的MSN8.5就无法登陆，老是提示我要升级。今天家里的MSN也无法使用了，被逼无奈，先用pidgin顶一阵再说。不过现在贝壳正在考虑MSN的用户搬迁工作，目标是迁移到Gtalk上，不行QQ。
    有几个朋友问贝壳，升级不就好了，何必兴师动众呢？首先，MSN8.5的安装程序只有20M，而MSN9的安装程序高达132M。其中多出来的100多M东西可不是白装的，他们大概会吃掉你30-40M的内存。而且9里面有很多插件(其实8.5也有，不过就一个，总算还好屏蔽)，安装上去后，工作的时候做调试麻烦异常，工作机器上装这个纯粹给自己找麻烦呢。而且微软素行不良，有劣迹在前。盗版黑屏问题大家还记得吧？升级提示上说是安全修补补丁，结果装上去屏幕就黑了。不说黑屏现在如何了，就说这种欺骗用户安装的手段，有谁还相信这次的强制升级是为了安全问题么？微软系统安全是出了名的差，一个安全公司用测试用蠕虫在win7上跑，只有20%不到能被微软自己拦截。其中固然有安全公司危言耸听，但是测试过程是全公开的，做假不来。这还是微软主推的最新操作系统，安全性据说很好。如果真是为了安全问题，先把Windows里面那堆雷死人的安全问题解决了才是王道。
    反倒是QQ的强制升级政策我觉得尚算可以。 QQ协议分为2005/2006/2007/2008多个版本，通常而言可以使用当前版本和前一版本。就是说，现在用的协议是2008的话，那么2007协议还可用，而2006协议就不再支持了。通常而言，这种时候继续使用2006协议的人微乎其微，基本可以忽略不计。这个政策主要是给不愿意升级的人一个缓冲的空间。对于腾讯而言，实施这个政策其实比微软更有压力。因为微软的协议是公开的，而腾讯则是采取封闭协议，甚至打击第三方客户端的企业策略。我们姑且不论这个策略的得失，但是维持两个协议版本，就给破解协议的人留下了破解的时间和空间。因此对于腾讯而言，这个策略是和公司战略相违背的。
    更深一层的问题是，强制升级问题说明了我们所依赖的服务的脆弱性。MSN在中国占据的客户群体并不算大，远远不比QQ。然而就是这样一个客户群现状，微软就敢于强制升级。今天是强制升级，明天收费呢？所以说任何事情依赖一个公司是不行的。我还是会使用MSN，但是会逐步将用户迁移到Gtalk和QQ上，并以开心网和Facebook做补充。力争做到这三个IM中任意两个能覆盖大部分朋友群体，开心和Facebook保留所有联系可能。这样可以适当制衡某些软件公司(不仅是微软，还有腾讯)，也可以减小出问题时的损失。
    其实要做到这点并没有任何困难。当你认识一个人的时候，只要和他保持两种以上的IM，并且在开心和Facebook(当然，这个没法强求了，毕竟中国的GFW...)上交换一下好友就好了。对抗强权，从小事做起就好。