记一次火车头采集器发布dedecms超级慢的处理过程

一直使用火车头采集，配合dedecms免登录接口进行网站的内容填充工作，但是一直没有挑战超过10w篇的采集环节。头几天自己找了个目标站，弄好采集规则后，就丢服务器让火车头采集没去管，结果搞出来60多万的文章量。想着采都采了，慢慢发呗。

image.png

结果前一两万发的速度还可以，后来是越来越慢，发布一篇文章要十几秒了，简直不能忍，跑了23小时才发了1.5w不到的样子。大概算了下，要跑40多天才能发的完！！！

001.png

下定决心要彻底解决下这个问题，在百度一通搜索无果后，只好自己研究了。我先是把dede后台影响性能的设置全关掉了，但依然没有改善。然后我又把目标转向了发布接口，将那些自动摘要，自动关键词的相关设置都关闭了，还是没有变化。简直挠头。
后来一想，还是老老实实跟下发布流程，看看慢在哪里了。自己模拟了火车头的发布请求，用postman测试。发现发布接口前面那些对文章的处理都没有影响速度，只是在最后发布那里慢的厉害。怀疑是发布的时候操作数据库拖慢了整体。去到mysql看了下，果然有慢日志出现。

003.png

看这个这个语句有点眼熟，尤其是哪个rand()，后来想起来，为了测试前台模板，文章页那里调取相关文章那里写了随机在全站取文章。赶紧去改成按点击量排序。再次发布，终于看到速度提上来了。

002.png

看来还是对dede底层的逻辑不熟悉导致的，对于大文章量的采集，要少在文章页搞随机取，或者全站取，减少数据库读取操作。