访问量大的话，CPU高很正常啊。

楼主没交代实际的访问压力。

还有找瓶颈的话建议开xdebug，使用profile看看具体分析报告。

当然xdebug会影响性能，生产环境建议单独部署一个开xdebug的环境，然后通过前端倒入一定比例的流量进行测试分析。

json_encode()

@lch21 putty里emacs能做到的程度已经很令人满意了，虽然256色已经是极限了

http://ww3.sinaimg.cn/large/6fe2fdc5gw1eelfkjtxvlj21hb0svwmp.jpg

@lch21 SecureCRT里的emacs有啥特殊？

如果在机械硬盘上操作，要考虑其特性做好适合的索引，仅仅排序的话未必做到最快，因为二分fseek还是会让磁头产生最多30多次随机定位，都知道随机读肯定不如顺序读

不考虑成本，排序后直接塞内存，大不了分多几台机器塞并发查就是了

@yueyoum "尽量避开mysql， 积分和另一个属性会频繁变动， 考虑10w级别用户"

这么点数据，mysql 内存表也可以试试看

@jacy 先试试简单点 POSTROUTING 上直接 owner 判断，不用MARK呢 ？
owner模块说可以直接用在POSTROUTING上

看看 <host>.err 文件里说了啥错误

@intosec 不是非常熟悉golang，就我所知goroutine的销毁只有从内部结束，看你f()里面怎么设计了，如果长时间处于运算中，而不做检测判断的话可能白白浪费计算资源。做个评估权衡一下好了，比如每查找1000次做一次检测看是否有其他f()已经完成。

@ETiV 推荐你一个东西 bitlbee ， 这个是把IM协议转到irc协议的东西，支持很多IM协议，比如gtalk

然后写个irc的机器人就可以了，毕竟IRC协议相对简单很多。

@Kabie 关闭input的时候，其它几个f() 不知道有个小伙伴已经搞定了，自己还在埋头苦干中...

13亿条，分页毫无意义啊

看看最近1000条么算了

作为隐藏图片发到热门网站热门帖子中，每个回复帖上几百张，小网站不用cdn的很容易就流量爆满

@yakczh

这个..... 上面只是一个基本框架

实际上确实碰到你说的情况，所以数据分析也分步骤的，并且队列也有多个分别对应每个步骤
或者在单个队列里面对的数据进行标记，表示它是那个站，哪个步骤的待处理信息

比如第一步，得到某个列表页，得到的url进入第二步的待抓取队列
第二步分析目标页，如果内容全了就ok，不全就增加步骤

所有步骤走完了才得到完整信息，中间某个步骤失败了，数据就是不完整的。


但是不管多少步骤，抽象出来每一步就是简单的 抓取->分析

“抓取”比较简单，就是准备任务扔给gearman，除非某些抓取需要带上特殊条件而需要一个特别点的实现
“分析”就是要针对不同站，实现每一个步骤的分析过程了

增加新的抓取目标站，就是做3件事情：
1. 定义新的站点，和步骤标记
2. 实现新的“抓取”，如果没有特殊性，可以用通用的
3. 实现新的“分析”

至于parser的实现，那就五花八门了，正则、DOM、json、甚至node.js解jsonp回掉数据，取决于目标站变态程度

目前我们实际用的就是这么个架构和流程，
rabbitmq中差不多有7G的消息队列，没办法抓取速度永远赶不上分析速度。
有时候内存吃紧，只能“忍痛”从队列中砍掉一大片

另外一点就是：如果存在多个步骤，那么后面步骤的抓取url要放入优先级高的队列，优先处理，要不然排到猴年马月也轮不上它