前文摘要/本文内容:
好的,我们已经把爬虫的脚本写出来了,写完之后,我们去执行,发现,实际上,在很多细节上,它并不是很好,正所谓,先实现产品功能,再做产品优化嘛,所以这一节,我们就分析一下,脚本都有哪些的不好,需要改善什么内容
线程单一:
整体的过程是这样的,获取一期的url,请求这个url,获取html代码,抓取壁纸图片url,然后再遍历下一页,如果遍历成功,继续下载壁纸图片。完成了一期的下载后,再进行下一期的下载。
单一的线程工作,好处就是,不会给机器资源带来巨大的压力,但很显然,它连机器1%的性能都没用上,剩下的资源造成了极大的浪费。
所以说,浪费可耻!因此,这个问题一定要解决!
想办法引入多线程技术,十几二十期url,一起下载,这样程序的效率才高!
情况单一:
我们的爬取,都是基于一个页面的规律来写的规则,其实,这个就是最大的问题,游民星空已经发展了15年了,页面版图可能觉得都差不多,但是,html代码不一定是一样的,脚本会精准的识别代码,就算版图的外观长的一样,只要是html代码改了一个字母,就会出现报错,导致脚本执行达不到预期的效果。
因此,需要引入异常判断的语句进去。
太多的网络I/O请求:
列表页有24页,每页有14期,每期大约有8页,也就是说,至少都需要2688次网络请求,实际上还会更多。要知道,网络这东西啊,你觉得它很稳定,实际上,它是断断续续的,基于TCP的传输是可靠,但是它的可靠是基于校验的,在实际上的底层物理层传输的时候,空气湿度稍微高一点,光纤的传输效率都会下降,长距离的传输,避免不了丢包的情况,哪怕是丢那么一帧,都有可能拉闸整个文件。
因此,尽可能的减少重复或者不必要的请求数量。
失败了就言放弃的下载:
想想看,如果我们在下载壁纸图片的时候,第一次由于网络原因,连接失败了,那么,程序就报错,结束了这次的壁纸下载,对吧,既然是网络原因,失败了,为什么我们不多尝试几次下载呢?
因此,需要引入一个尝试重新下载的机制。
不够专一的程序设计:
其实,程序设计和公司架构的发展很类似,一开始,规模小,公司的老板,既是将军,又是马仔。当规模大起来之后,就出现了专项职能部门,比如人力资源部啊,财务部啊等等。
因此,这个爬虫可以分成这两个专属职能
1、爬行获取url
2、根据url,下载图片
结尾:
所以说,分析完这些问题之后,下一步,我们就要着手去优化这些东西,以便达到更高的程序执行效率。