JB的测试之旅-记一次百度爬虫历时问题经历

　　前言

　　在开始之前，想说下抱歉，如果是抱着解决问题的看法进来的话，对不起，让你沮丧了，本文不会讲解如何解决这问题，因为研制说不处理了，但本文会介绍是怎样一街过来的，如果还感兴趣，请继续看~

　　上几篇文章有介绍到，jb在负责一个seo的项目，关于seo是哪些，请点击这儿查看;

　　自从项目上线后，一波三折，遇到不少坑，其中在前面那篇文章里提到到，这里就不说明了；

　　某三天，运营老大贴了如此一张图：

　　(把日期打码了，问题不大)

　　从这个截图数据上看，爬取历时平均值932ms，最小值106ms，怎么看都认为合理，只是那种最大值300s的，看上去好别扭。。

　　接着，我们用里面的内容辩解说，平均值看上去很正常，应该没啥问题吧？

　　运营老大说，但是我们愈加关心最大值，以前的产品都没有这些情况的，最大值都不超过1000的，基本都是500-1000ms;

　　从这时起，开始get不同技能了~

　　网站介绍

　　百度数据

　　因为这个爬虫是百度的，而这个爬取历时的数据，也是百度提供的，理所当然要瞧瞧，这个值是如何算下来的，遗憾的是，百度的平台没有任何与爬取历时有关的信息;

　　既然这么，那就Google，内容为：百度爬虫历时太长，在搜索的结果上面有很多百度爬虫的介绍，但是并没有任何一条有直接讲解到这个百度爬虫历时是如何算的~

　　问了好多同学，甚至是百度内容朋友，都不清楚，所以，这块数据对于开发者来说，是一个全黑盒的玩意儿;

　　既然这么，我们就先假定，这个时间是指发起恳求后，到获取响应且渲染完内容的时间；

　　后端日志

　　拿到问题，第一反应就是使前端的朋友查下日志，看是不是真的出现300+s的情况， 但实际查询后发觉，并没有出现此类情况，后端的日志显示插口返回都很快，基本是ms级别，秒都谈不上，更何况300s?

　　既然前端没有问题，那就肯定是后端了；

　　前端

　　既然怀疑是后端问题，那我们就尝试再现下吧，

　　直接用Chrome按F12步入开发者模式， 直接刷新试试，手动重复几十次，基本都是2这个区间内，而且首页资源非常多，如果首页都没问题，其他页面就更不会有问题了；

　　（手动重试中） 突然会发觉一次历时比较久的，长达10s，看了下时间的占比，如下：

　　咦，一个图片用了3s？什么鬼？ 而且会发觉，有些图片size会高达4M?

　　瞬间把端倪之前了资源这块，为了验证我们的看法，使用了webpagetest工具来验证下网页的历时，这个工具是个网页，直接打开输入须要测试的网址即可；

　　先来一次结果：

　　直接看底部的截图，嘤嘤嘤，fully loaded time竟然去到16S了，这肯定有问题，接着继续看：

　　啧啧啧，一个图片的下载用了8S，这性能不太行啊，而且有些图片的size的确很大，所以第一反应是，图片压缩，减少size，另外，网站本身会时常出现404，这块本身都会影响到seo的收录早已爬取，在这些情况，不得不怀疑任何一切相关的，因此就撸起衣袖开始干了：

　　1）资源压缩，部分业务逻辑合并，减少恳求数目，缓存机制

　　2）出现404的缘由是，当初设计时，如果诸多插口里某一插口异常，前端直接判断伟404，因此把这块逻辑更改下，接口异常不会造成后端跳404，最多是数据不展示；

　　开发、测试、上线、绝望，一泼热水浇出来百度爬虫日志，大家都萎了；

　　几个臭皮匠一起讨论了半天，也没个推论，此时百度爬虫日志，部分朋友认为这是个费力不讨好的工作，慢慢的开始淡出这个工作了，有点所谓的选择性失盲了；

　　再次剖析

　　即使营运老大、老板天天问，但是仍然没有任何进展，这问题，就如此坑人？

　　此时，某拍*敏*感*词*朋友(php)主动（被迫）出来跟进这个问题;

　　啪啪啪好几天过去了，突然某三天，钉钉群了，该拍*敏*感*词*朋友给出一个方向，

　　这个问题有初步怀疑点了，那就是服务器带宽问题引起的，解决方案就是临时扩充带宽；

　　怎么剖析的？

　　既然能给出这样的推论，肯定是有数据支撑他的，那我们就来瞧瞧，是哪些支撑他这个推论；

　　依旧是先剖析后台日志，过滤百度过来的恳求，

　　某一条有40几个，然后再按照插口响应超过10S的方法进行过来，发现剩下2条日志：

　　从日志上看，基本历时都在18S，也读是百度爬虫那过来的；

　　既然都有日志了，那就模拟下瞧瞧是不是真要那么久，这里的模拟爬虫用的是百度熊掌号自带的工具：

　　输入出现问题的地址，结果如下：

　　只须要关注最下边的下载时长：0.166s，重复多几次，依然这么;

　　这个后台的日志不一样，那就说明，这个问题不是必现的，而且有特定场景引起的；

　　从后台的日志上看，刚爬了几次的日志，也的确跟百度上显示的类似，那说明百度上的时长是可信的：

　　从上图可看出，最大一次也不超过3S，与一开始反馈的300S相差甚远；

　　此时再去看下服务器的情况：

　　服务器是5M的带宽，从日志上看，的确有部份时间段是超过了5M，而且出现爬取比较慢的时间正好对的上服务器超过5M的时间；

　　因此该朋友才敢说，怀疑是因为带宽，虽然听起来有点巧合，但是在万般无策的情况下，只能相信是这些巧合了；

　　然后就调整带宽，观察几天，毕竟爬虫这些东西是靠他人的，心急不来，在等待的期间，做了4件事：

　　1） 资料查询借鉴

　　导致抓取时间达到几十万的情况

　　1.2） 抓取该页面的时侯部份图片未能抓取到；

　　1.3） 链接超时；

　　1.4） 百度内部调整造成；

　　从结果看，个人倾向1、2可能性大；

　　2）跟后端朋友沟通下，后端返回的18S，是如何的标准？

　　回到文章顶部，有提到到这个网站架构是node+nginx+php,那这18S， 按照理解，应该就是Php返回到nginx的时间，那nginx到node中间传输会不会也有耗损，比如跟网速有关系、服务器性能等，都有可能有折损，然后node接收后，再渲染显示，等渲染完成，爬虫才觉得整个过程完毕？（前面提到到，这里默认爬虫规则是开始恳求到渲染完毕，但实际未知）

　　当时提及一个疑惑，假如说，node或则nginx有问题了，那是不是都会出现历时太长的情况？

　　但当时由于没数据支撑，大家都认为，嗯，有这些可能，这种看法一闪而过，但是有哪些缘由造成node或则nginx有问题，真没想到；

　　事实回头看，猜对了，的确是node出问题引起；

　　当也由于当时没想到，后面才更好的梳理了；

　　3）影响网路传输的缘由有什么？ 找到一个答案，不知道对不对，仅参考：

　　最重要的两点就是带宽，并发数，带宽验证是没影响，那这个会跟并发数有关吗？

　　再次梳理

　　回到正文，上线几天后发觉，还是不行，依然有问题，说明带宽不是问题点，那如何办？

　　上面提到到，既然带宽不是问题，那就可能跟并发数有关系了，而且爬虫过来肯定也是并发如此过，所以就把端倪对准并发了；

　　但是在实际去看并发之前，还是把逻辑梳理了一遍：

　　根据前面的信息，现在从前端nginx可以get到的是，PHP和前端处理时间特别快，基本在0.1-0.5之间；

　　从流程上来看，前端负责接收和返回前端的是nojs,所以有理由怀疑，异常发生的诱因是在node层，结合前面的并发可能性，有可能是多并发，导致nojs进程cpu占用负载，导致处理时间加长。

　　这样也能挺好地解释，为什么有的时侯，抓取的时间只须要0.1到0.5，但是有时却须要消耗历时20万毫秒；

　　既然有所怀疑，那就开始干吧~

　　实验

　　本次的实验目的很简单，就是在高并发的环境下，进行百度爬取的行为，看看数据是不是正常；

　　工具的选择，不苦恼，压测用apache ab，原因命令行，便捷，爬虫就直接用百度自带的；

　　分3组数据：

　　1）不使用并发，直接使用百度爬取

　　2）针对具体某一新闻页进行并发，并且爬取这条新闻页，链接

　　并发命令：

　　结果发觉，尝试多次，第三种情况下总算出现了抓起失败的情况！！撒花~

　　ok，虽然不是百分百能再现，但起码再现到一次了，也就说明的确有问题的；

　　下面是点击百度上的查看帮助里的内容：

　　Ok,拿着这个去跟后端反馈，结果后端负责人是如此回答的：

　　会处理；

　　嗯，这个问题就这样算是有个交待了；

　　小结

　　总结下此次遇见的问题吧 ；

　　收到问题->寻求数据怎么统计->分析前端日志->压缩图片size及处理404问题->再次剖析，怀疑跟带宽有关系->重新梳理流程->怀疑并发->验证->重现问题;

　　其实从里面的流程来说，貌似没太多的问题，在不了解或则不熟悉的业务上，也只能不停的去排查来验证表象；

　　但有个最大的问题是，像这类问题，理应第一时间想到并发跟带宽，但是在此次却是最后才想到，由此可见敏感度不够，无论是测试还是研制，对这些问题跟进能力比较缺乏，后面须要强化这类问题的敏感度；

　　上面提到到的压缩图片size和处理404的问题，即使没有此次的反馈，从网页本身考虑，本身就是须要去做的事情；

　　apache ab介绍

　　对于网站而言，压测是必须要做的工作，那压测的工具有很多，jmeter，loadrunner，ab，那为何会选择ab？

　　个人认为主要的缘由是边界，命令行，windows\Linux\mac都支持使用；

　　下载安装

　　因博主笔记本是win10，所以是以windows的下载来述说，请了解；

　　2)打开链接后，点击红框的Files for microsoft windows

　　3)打开后，点击红框的ApacheHaus

　　4）向下滑动，鼠标点击晓红框里的内容，就会手动进行下载

　　但是试过好几次可能是网路缘由，下载太慢，而且可能会断掉，因为剖析一个2.3.4.3版本的zip包，需要的朋友自取：

　　下载完就解压，使用Windows下的cmd命令行，去到刚解压的目录下的bin目录;

　　然后输入ab，如果不报错，则说明是成功了；

　　当然，有朋友认为每次都进来这个目录很麻烦，那可以把Apache24\bin这个路径配置到环境变量，后续就可以直接ab使用了，具体Windows下环境变量如何配置，网上搜索下，很多的~

　　直接压测网站

　　执行后，就会有右图的结果输出：

　　压测就是如此简单，但是要剖析上图的内容，才有价值 这一陀看不懂？没关系，下面教你如何看

　　ab命令参数说明

　　第一次使用ab命令时，不知道有哪些参数，可以输入ab -help，然后才会弹出如此一坨东西：

　　一般常用的参数就下边几个：

　　更加多详尽参数说明：

　　实例

　　ab -n 3000 -c 3000

　　ab -t 60 -c 100

　　带参数的的恳求

　　ab -t 60 -c 100 -T "application/x-www-form-urlencoded" p p.txt

　　参数中的三种方式

　　结果剖析

　　执行完后，会有如此一坨东西：

　　下面就来讲解，到底是哪些意思：

　　使用ab常见的问题

　　1）ab命令在通常系统里面做测试时侯，一般并发不能超过1024个，其实是因为由于系统限制每位进程打开的最大文件数为1024，可以用ulimit -a来查看;

　　2)-n 可以指定最大恳求数，但是不能超过50000个;