wifi是facetime必备的环境，想想之前尝试的都是不靠谱的人，不是没有wifi就是有了wifi也不上。所以不成功是理所应当啊。技术没问题，还是人的问题。

飞信开通了邮箱注册，可能会用邮箱注册一下继续用工作用途。就是不能线下收离线消息了。不得不说，飞信算是个杀手应用，主要在免费短信上，黏性还是有的。

自己是个很喜欢做slide的人，不过近一年多时间太忙，都没有好好做一下，只是在别人提供的基础上改一改而已，其实效果很不满意，但是没办法。工作嘛，就是这样，时间太少的时候，只能牺牲品质了。所以平时讲的那些Presentation也就相对乏善可陈。

作为一个Macbook的用户，对Keynote的喜爱到了无以复加的地步，工作中用着thinkpad+powerpoint简直就是折磨。很怀念08年悠哉悠哉在沙发上把自己一些不着边际的想法写在slides里面的时候。只是一个未完成版，很可惜，很多东西，半途而废了，无论是因为什么原因。但是，未完成本身并改变不了什么。最后留的url,是我另一个域名，也已经永远的成为历史了。因为年代久远，其中必然有一些错误。懒惰的我也没改。惭愧！

Presentation和拍照一样，更多的是考验人的表达能力（当然你也得肚子里有货才行），懂得站在听者的角度去整理自己的思路。因此做讲演做得好的人，通常在平时接触中就是温润如玉后发制人型的。总是要有卓越的洞察力才有后面的事情。不然啥效果也搞不出来。

嗯，好像题目起的很俗….

你的QQ号码注册时间为：1999年11月1日 [仅自己可见]
你的Q龄为：11年

工作以后，qq实际上已经淡出，从05年到现在，基本上登陆的时间加一起也就几个月。MSN成为了主力，最近飞信多了，MSN又被冷落。自始至终，最简单最不像聊天工具的，反而是我的最爱；沟通和聊天是两回事。所以qq和msn上，不常能见到我的身影了。注：飞信注销以后被强烈要求重开。

回想过去这11年，自己的变化很大，通讯方式的便利让四海之内皆兄弟，但是竟想不出过去生活里任何一件具有重大意义的事件
是跟QQ或者别的IM相联系的。手段永远是手段，真正决定性的，是目标和决心。

P.S. 删了SNS账户（开心网）以后，发现一天的时间变多了，看来很多时间浪费在无用的地方而不能察觉。SNS满足了人们了解社交圈子状况变化的需求，但是人总是倾向于滥用工具。信息爆炸带来的问题体现在所有细微方面。

刚好几天前，删除了全部的SNS和大部分IM. 巧合的是，名字都起的很相似，诡异。另外，莫沉迷于任何会让你沉迷的东西。

1. Kaixin001.com 可以成功销户，赞一个
2. Sina微博 没有销户选项，只能删掉全部follower和fans
3. Facebook 没有销户选项，只能将账户休眠，别人见个僵尸账户在上面
4. Twitter 没有销户选项，只能手动删除各种关系，考虑到在墙外，实质休眠
5. Linkedin 这个更扯，各种关系只要建立就不能删除，删除失败，也不能休眠，流氓一个
6. 各类聊天软件，除了飞信可以注销用户，别的好象都没有销户功能。

综上，在互联网上，你的存在很简单，开帐号特方便，想要销户就麻烦多了。特别表扬Kaixin001,虽然是抄袭facebook的，但是考虑的比较周详，连Facebook没有的销户功能都提供了，作为有部分负面效应的功能，kaixin001依然提供给客户，着实是大家风范。人之自信者当如kaixin001，因为真正的关怀，不在表象

营业员态度不错，先问家住哪，是不是五环以内。说是五环以外网络还不行。这事早在网上就听说了，不易外。反正在北京五环内和出差的时候能上就行。接着被追问去那里出差。大汗，原来只有10来个城市支持，包括天津、上海、沈阳、深圳、广州等等，而且也和北京一样，不敢保证覆盖范围，估计只有中心区可以。其他地区都是2G速率，营业员坦言2G的速度肯定很慢。看来移动确实在TD-SCDMA上吃了不少苦头，不然也不至于沦落到这步田地啊。

不管怎么样，人都来了，好歹试一下设备，看看在mac上能不能用。网上流行的华为ET-128在营业厅没有，现在都是换成大唐的了，插上以后果然告知不可识别。这下子真的死心了。

改天去联通看看吧

中软 IT项目经理
Real Networks BI职位
中金 DW职位
国家进出口银行 IT管理职位
某e-business公司 产品开发经理职位(期权若干)
某咨询公司 高级技术经理职位
某硅谷创业公司 高级工程师职位
某第三方支付公司 技术经理职位
某银行信用卡中心 IT项目经理

加上之前的公司，这辈子面试过的公司还有：

NCR
IBM
ICBC
Gomez (10月份被compuware收购了)

胜率超过60%，还算令人满意

第一份工作的时候在银行业，有些表每天的新增数据就有2.3亿条记录（拜大集中所赐），这还只是半个中国的数据。因此从一开始，对大规模数据的处理就是我工作的基本要求。前辈们总结处很多编程与操作的规定，以满足性能上的需要。这里的性能，更多的指在规定要求的时间内完成规定的事情。在这段时间，没有人会提“千万级数据”，因为它太少了。

后来进了DB2的老家IBM, 做起了DB2的技术支持，那些DB2的开发设计大牛来讲DB2的架构，各部分的实现原则与部分细节，终于从更深层次了解了数据库是如何操作数据的，如何计算，如何join, 优化器如何改写SQL并决定访问路径(Access Path － 话说这中文翻译还真是别扭).这背后其实是cost-based estimator, 一切皆以statistics统计数据作为输入，进过DB2优化器的数学模型，得到对结果集大小、CPU时间、I/O时间等等的预测，最后得到一个时间估计，选取估计值最小的方案。

每个人都希望自己的查询(query)有快又好，但这是要跟多种因素相关联的。除了优化器选择access path以外，跟DB系统参数，Bufferpool大小，Sortpool大小，CPU,IO性能都有关系。

当然，大部分个人用户不会考率为了数据库的性能而更换或者扩展CPU数量，换用高性能的企业级存储这样的要钱的方式，因此就省下压榨database系统了。因此在互联网建站和小型企业数据库上，才更多的提到“千万级”的概念 －－世上本没这个词，提的人多了也就成了个概念吧。

网上一个不算新但是很详细和典型的帖子：http://www.xiaohui.com/dev/server/20070701-discuz-mysql-cpu-100-optimize.htm

一个典型的场景就是系统突然出现了一个状况（CPU high或者响应慢到不能忍受），于是要分步排除问题，首先系统IO方面时候遇到瓶颈－－打开文件数量到上限了？cache出了问题？这个部分没问题了，再看看DB系统的配置参数如何？是不是bufferpool或者sortpool大小不合适所以导致了过多的page-in,page-out?

如果上两点都没有问题，初步可以排除环境方面的因素，接下来就可以关注在具体SQL query的性能了。

那么关注哪些SQL呢？常用的关系型数据库系统(DB2, Oracle也包括MySQL等等)，都有工具或者命令抓到耗时最长的SQL query. 例如MySQL下你可以用show processlist;

找到了最慢的sql,有两个方向可以选择：A 从SQL Query涉及的object(table,view)出发分析结构上的欠缺如缺少必要的index等等；另一个方向是用explain得到slow SQL的access path, 看看是不是table scan了，发生在什么环节然后去做修改。

上面是最最通用的数据库调优(Performance tuning)的策略，基本宗旨还是我们创造条件去帮助优化器(DB optimizer)以得到最优解。相信大部分DBA都熟悉。接下来说一下一个极端情况，就是无论你怎么做，优化器认为的最优解在你的特例中实际上却是最糟糕的。我们不能神话优化器，没有一种算法是能够在所有情况下都是最好的，因此极少数的SQL在特定的data特性下，我们需要去“误导”甚至是“欺骗”优化器来的到我们想要的最优解－－即便这个方案在优化器看来是很糟糕的。这就是access path hint, 名字可能略有差异但是DB2,Oracle等主流数据库系统都是支持的。我们可以用自己的大脑代替优化器来决定少数特殊query的access path.

啰嗦了这么多，其实是想说，被常常使用的“千万级数据（库）”的概念，其实跟技术没多大关系，只是一个模糊的对DB甚至是整个IT系统的性能要求，有时候可以理解为性能调优技术的要求。以后见到这个概念，知道背后是怎么一回事就行了－－尤其是对HR和猎头这类技术盲来说。

P.S. 数据库还有另一个scaling方面的技术来提高性能，这个是架构方向，互联网企业用的比较多。以后有空再写一写。其实网上这样的文章很不少了。

“你有 179 張相片儲存在 Flickr 上。達到 200 張後，你將需要升級至 Flickr Pro account，否則你將僅可以查看最新的 200 張相片。
我們將不會刪除任何內容，而且如果進行升級，你將獲得無限空間以儲存所有內容。或許你想要立即升級至 Pro？”

1. Heroku是架构在Amazon EC2上的，具有不错的扩展性，只要你有钱，拖拉一下鼠标就能实现scaling了。这一点着实很方便。当然代价是价格会比EC2高，毕竟人家提供了增值服务嘛。具体高多少很难比较，连heroku的老板都说对应关系很复杂。基本上要是网站做大了，用heroku就不合算了。

2. 不烧包的就用heroku的free配置，只有一个dyno的，5M存储空间，可以支持绑定自己的域名。

3. 近期遭遇了几次request time out,因此查了一下heroku doc，dyno基本上把它看成一个线程吧，换句话说，这个一个dyno的free版只能支持并发度为1的压力。因此并发连接多的化，你会经常看到time out的。计算容量也是比较寒酸，用ab -n 10 url测一下，10个请求4个fail掉了orz. 看来免费的午餐也不好用啊。大家用来做原型demo就好了，验证好了自己找地方去deploy也挺好。

update：不知道是这次测试当时受海底光缆受损的影响还是其他原因导致结果很差，后来新的测试比较正常，后面我贴了一个新的benchmarking的测试结果。free的计划还是可以承受一些负载压力的。特此给heroku正名

4. heroku提供了deploy代码的好方案，但在DB方面限于技术原因，还比较薄弱，mysql什么的还是用不起来。

5. google map API是跟域名相关的，如果没有自己的域名的话，部署到xxxx.heroku.com这种子域名下面是不能用的，想必早有人在heroku下面申请了key, 后来者都会遇到冲突。花钱买自己域名吧

6. Heroku的想法不错，这也难怪他们会积攒了数万用户，也得到了300万美元的投资。云计算，不再是一个概念了，已经有若干成熟的方案面向消费者了。这一点要向先行者amazon致敬

7，最后一点就是heroku的支持做的不怎么样，文档也很不完整。遇到问题还是要自己摸索解决。

add-on: AB benchmarking result:做了两个测试，一个是简单到极致的逻辑，另一个相反，是复杂到极致的逻辑，看看两个边界状况的对比和共性应该更能说明问题：case1表现不错（里面就两行code当然不错了，呵呵），case2太复杂了，failed了88个（一共100个请求，FT）.

case1: light code:
localhost:sinatra tony$ ab -n 100 -c 10 http://ip2loc.dazhe.me/counter/
This is ApacheBench, Version 2.3 < $Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking ip2loc.dazhe.me (be patient)…..done

Server Software: nginx/0.6.38
Server Hostname: ip2loc.dazhe.me
Server Port: 80

Document Path: /counter/
Document Length: 15 bytes

Concurrency Level: 10
Time taken for tests: 7.828 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Non-2xx responses: 100
Total transferred: 26200 bytes
HTML transferred: 1500 bytes
Requests per second: 12.77 [#/sec] (mean)
Time per request: 782.820 [ms] (mean)
Time per request: 78.282 [ms] (mean, across all concurrent requests)
Transfer rate: 3.27 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 309 389 192.2 317 1233
Processing: 316 378 272.2 337 3050
Waiting: 314 377 272.3 335 3050
Total: 627 767 332.5 661 3370

Percentage of the requests served within a certain time (ms)
50% 661
66% 677
75% 705
80% 815
90% 1017
95% 1543
98% 1570
99% 3370
100% 3370 (longest request)

case2: heavy code:
localhost:sinatra tony$ ab -n 100 -c 10 http://ip2loc.dazhe.me/
This is ApacheBench, Version 2.3 < $Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking ip2loc.dazhe.me (be patient)…..done

Server Software: nginx/0.6.38
Server Hostname: ip2loc.dazhe.me
Server Port: 80

Document Path: /
Document Length: 696 bytes

Concurrency Level: 10
Time taken for tests: 24.932 seconds
Complete requests: 100
Failed requests: 88
(Connect: 0, Receive: 0, Length: 88, Exceptions: 0)
Write errors: 0
Non-2xx responses: 88
Total transferred: 36676 bytes
HTML transferred: 10992 bytes
Requests per second: 4.01 [#/sec] (mean)
Time per request: 2493.243 [ms] (mean)
Time per request: 249.324 [ms] (mean, across all concurrent requests)
Transfer rate: 1.44 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 310 328 28.1 316 410
Processing: 614 2067 790.9 1961 3904
Waiting: 613 2066 790.9 1960 3903
Total: 977 2395 788.1 2370 4214

Percentage of the requests served within a certain time (ms)
50% 2370
66% 2645
75% 2888
80% 3086
90% 3569
95% 4036
98% 4177
99% 4214
100% 4214 (longest request)