tornado+gevent 解决绝大部分问题

@ShiHou GIL 是全局解释锁，会导致多线程没用，进程之间是没有隔离的

@0x5010 我跟公司写过这种统计大概每天统计请求一百万吧，这个并没那么难，如果只是存储访客信息， nginx+tornado*4 然后用 mysql 存储就行，为了让 mysql 压力小一点 100 次请求才提交一次事务，机器配置也不高 2core+4g 内存。
如果是做广告 dsp-trace ，有几种方案可以做
1.给用户设置 cookie ，请求接口将广告显示出来，然后后台数据库用 redis 设置一个 kv 就行（某个用户 某个时间访问了某个广告的 ID ），聚合的时候根据 cookie 去找，很容易通过这种方式去进行各种维度的聚合，其实去了根据维度去重复后数据量还好（其实产生的时候基本上到 redis 的时候就已经是个完整字典结构了）
2.还有将数据分布存储，隔一段时间 hadoop 或者 spark 进行离线计算，把相关数据库存储到 monogodb 里面去，前端展示结构从 mongodb 里面查询

@yeyuexia numpy log 没啥用，但是用矩阵计算性能优化很大，这个不是 c 和 Python 的问题是算法复杂度的问题

@Zzzzzzzzz @yeyuexia 我早看到了啊，这些都没什么用，多核计算并不能提高这块的计算速度来到多大的性能提升， cmath 和 math 比较好像并没有多大个区别

@yeyuexia numpy log 和 math 比较还没 math 快, 进程线程协程都没有什么用，用了反倒会变慢，毕竟不是 IO 密集型操作

这个世界还是需要一个共享的精神， linux 是完全免费的， mysql 是完全免费， java 也是免费的等等世界顶尖的产品都是免费！自由开放不应该被恶意揣测，我公开一个我自己的 http://blog.xenvoy.org/

@calease 我肯定测试过的啊，
@yepinf 用 c++也不一定比我快啊

@vm 与产品经理斗其乐无穷；与测试斗其乐无穷；然后可以安心写代码

@ShiHou 感谢你的热心帮助，我测试了才知道主要速度卡在统计词频上面，跟多线程啥都没关系。后来想起来 python 本身就自带词频统计模块, collections,发现在最近记忆力下降了
代码就变成了
counter = [i for i in xrange(100000)]
# 得到某一个词的词频就是
counter[words] # 变成了查 hash 了
实际测试速度：处理 30 万词，消耗 6 秒

@ShiHou 这种运算下面多线程和 coroutine 并不能带来速度多少的优势

@ShiHou 差不多就这个意思，数据量大了后就开始特别慢了，也就是 20 多万而已

设置好主键把内存池和线程打高一点设置好索引，其余交给数据库吧

看毛泽东思想，看完之后你就可以大大提升了

没 USB 插口一律差评

@yumijie 很多都是你自己留下的

@murmur 我说的是基本，代表很多，而不是全部，你非要找出例外出来，我只能告诉你里面还有事基于其中还有很大一部分是基于 scrapy 开发的，你可以继续找例外出来

@cdwyd mmap 读取文件，然后用 set 去重， mmap 申请的不是 buff 而是内存分页，只要你是 64 位系统就能突破限制