@est 起码是对mysql的访问，要非阻塞就只能换纯python的mysql库了

@est gevent的数据库访问也还是阻塞的

锁噶，这事应该去微博找 @sir阿怪，呵呵

@ywencn 主要是性能问题造成的可攻击的入口，比如找准一个慢查询，也就是LZ说的200ms那个，很轻松的就能让一个网站失去响应。

换 iPhone 吧

@SamRaper 这个情况是上了ajax反而会增加更多的请求，雪上加霜，ajax并不能解决性能问题

@pubby rpush是纳秒级别的操作，且，每个请求慢1ms，但是总体的处理能力上了一个数量级的台阶，还是划算的。你不能单独看一个请求的得失而忽略了总体的吞吐量

@est 这里是典型的生产消费模式，不用pubsub都可以，直接blpop就可以了。而且访问redis都可以是异步的。具体的方式是比如16个tornado进程负责接收请求发送输出内容，然后启动N个工作进程来处理业务逻辑和渲染页面输出json什么的，blpop到一个队列，tornado进程rpush到这个队列，然后工作进程就去处理业务逻辑就行了，有些慢查询难优化的可以放到独立的队列中去，这样mysql的负载是一个恒定的，连接数是恒定，前端的tornado完全异步化了，如果遇到个别耗时很长的操作也不会堵塞其他请求。

当然缓存啊数据库优化啊什么的还是照做，这只是我觉得比较合理使用tornado的一个方式而已。

@Numbcoder 很多时候并非跑得快就是好，死快死快，死得也快。postgresql的稳定性是杠杠的。

@est leveldb我用过超过大半年了，业务场景也很简单，就是短链接生成，老实说，量大了也不行。

tornado没有解决db同步的问题，所以在耗时访问多的时候被堵在数据库IO上，再快也是百搭。

有个解决的办法就是，通过redis把请求异步到后端的队列里处理，完成渲染页面或者生成json后再输出，这样数据库的压力是平滑的，即使遇到个别慢查询也不会影响其他访问

@Numbcoder postgresql相当靠谱

@pythonee we have the practice but not the best

@pinkman 随手写的写复杂了点
[{k:v} for k,v in dict([d.items()[0] for d in t1]).items()]
简化后就这样了，其实dict([d.items()[0] for d in t1]).items() 以外的部分纯粹是为了把列表内还原成一个个字典

[{k:v} for k,v in dict([list(d.iteritems())[0] for d in t1]).iteritems()]

搞定收工

做远程抓娃娃机

@laogui 极客集可以对比一下先看看（xiankankan.com） 。看到新奇的东西就会想买来玩玩，然后先看看可以买，极客集无法买，然后也就只能看看作罢了。

@cxe2v 在速度较快的电脑上修改路由表的话一张网卡也行的

@devon 和分红的1000多万元设备 用设备抵分红？

@yueyoum bingo

@scg16 既然是尸体了，送给大山里的同学，让他们看屏幕发呆么？