写爬虫是一项复杂、枯噪、反复的工作,考虑的问题包括采集效率、链路异常处理、数据质量(与站点编码规范关系很大)等。整理自己写一个爬虫程序,单台服务器可以启用1~8个实例同时采集,然后将数据入库。
同一个分析日志的awk脚本,在Centos、ubuntu操作系统运行效率存在巨大差异。即在ubuntu中只需1分钟,而在Centos中则需要20分钟。以下为我的排查步骤:
1、检查服务器内核版本
拿一台升级过最新Linux内核(2.6.32.3)的CentOS5.4服务器来测试,结果还是没有改善 。
2、检查内核ulimit参数
在Centos服务器调整所有ulimit参数与ubuntu系统一致,结果还是一样。
3、优化awk脚本
由于mawk与gawk部分语法上存在差异,如将转义符‘\’换成'\\',双引号换成单引号,依然没有效果。
4、检查gawk版本
检查两个系统的gawk版本,发现所有Centos版本默认自带的gawk都低于ubuntu系统自带的3.1.6,尝试在Centos服务器下载、安装源码gawk3.1.6,结果速度提升了20倍。测试结果如下:
time /usr/local/bin/gawk -f test.awk access.log >"temp.txt"
real 0m48.739s
user 0m42.904s
sys 0m5.389s
1、检查服务器内核版本
拿一台升级过最新Linux内核(2.6.32.3)的CentOS5.4服务器来测试,结果还是没有改善 。
2、检查内核ulimit参数
在Centos服务器调整所有ulimit参数与ubuntu系统一致,结果还是一样。
3、优化awk脚本
由于mawk与gawk部分语法上存在差异,如将转义符‘\’换成'\\',双引号换成单引号,依然没有效果。
4、检查gawk版本
检查两个系统的gawk版本,发现所有Centos版本默认自带的gawk都低于ubuntu系统自带的3.1.6,尝试在Centos服务器下载、安装源码gawk3.1.6,结果速度提升了20倍。测试结果如下:
time /usr/local/bin/gawk -f test.awk access.log >"temp.txt"
real 0m48.739s
user 0m42.904s
sys 0m5.389s
一、前言
由于目前部分平台所使用的Linux发行版版本比较低,自带的内核版本远低于主流内核,无法使用到一些优秀的新内核特征,包括对我们比较有用的per-task storage I/O、改善在SMP系统中I/O的吞吐量、Ext4文件格式、虚拟化支持等。因此决定采用目前最新稳定版内核Linux-2.6.32.6(更新于2010-01-25)进行重新编译,生成一个更加小巧、稳定、安全、高效率的新内核。
二、编译步骤
第一步:
# cd /home
# wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.5.tar.gz
# tar -zxvf linux-2.6.32.5.tar.gz -C /usr/src
# cd /usr/src
# ln -s linux-2.6.32.5 linux
# cd linux
第二步:
# make mrproper (初次编译内核这步也可以省略,方便第二次编译初始用。)
# make menuconfig
# make bzImage && make modules && make modules_install(需30~40分钟,具体看服务器配置)
# make install
由于目前部分平台所使用的Linux发行版版本比较低,自带的内核版本远低于主流内核,无法使用到一些优秀的新内核特征,包括对我们比较有用的per-task storage I/O、改善在SMP系统中I/O的吞吐量、Ext4文件格式、虚拟化支持等。因此决定采用目前最新稳定版内核Linux-2.6.32.6(更新于2010-01-25)进行重新编译,生成一个更加小巧、稳定、安全、高效率的新内核。
二、编译步骤
第一步:
# cd /home
# wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.5.tar.gz
# tar -zxvf linux-2.6.32.5.tar.gz -C /usr/src
# cd /usr/src
# ln -s linux-2.6.32.5 linux
# cd linux
第二步:
# make mrproper (初次编译内核这步也可以省略,方便第二次编译初始用。)
# make menuconfig
# make bzImage && make modules && make modules_install(需30~40分钟,具体看服务器配置)
# make install
由于应用要求对更新过的页面需要进行实时更新,如新记录的数据发表、修改、隐藏等操作,目前有两种方法可以实现,第一种为在应用平台结合Varnish的Purege进行处理;第二种为利用http request的header做相应的处理,比如页面的redirect/header、按F5或Ctrl+F5键都会向服务器发送不同的Cache-Control,再将非更新页配置obj.ttl=86400s(1天),这样可以大大提高缓存的命中率。以下为采用第二种方法针对不同浏览器的测试结果。
1) 默认配置下的浏览器响应

结论:在默认配置下浏览不管发送任何类型的Cache-Control,Varnish都不会对Purege进行处理。
2) 配置Cache-Control的no-cache时的浏览器响应

结论:说明Firefox浏览器只有按Ctrl+F5时才会发送no-cache的Cache-Control,IE浏览器认为服务器端的redirect的重定向就是一个no-cache,同样按Ctrl+F5也如此。比较奇怪的就是Chrome浏览器即使按Ctrl+F5后同样没有向服务器端发送no-cache,后来查了资料,得知google为了更好的利用本地cache,将Ctrl+F5的功能屏蔽。
3) 配置Cache-Control的max-age=0时的浏览器响应

结论:通过上表数据可以得出,Firefox在redirect的情况下,它会发送一public或Private的Cache-Control给服务器端,同时IE及Chrome都会以一个max-age=0的Cache-Control的标志给服务器,此时的Chrome浏览器Ctrl+F5没有发送no-cache,而是max-age=0。
1) 默认配置下的浏览器响应
结论:在默认配置下浏览不管发送任何类型的Cache-Control,Varnish都不会对Purege进行处理。
2) 配置Cache-Control的no-cache时的浏览器响应
结论:说明Firefox浏览器只有按Ctrl+F5时才会发送no-cache的Cache-Control,IE浏览器认为服务器端的redirect的重定向就是一个no-cache,同样按Ctrl+F5也如此。比较奇怪的就是Chrome浏览器即使按Ctrl+F5后同样没有向服务器端发送no-cache,后来查了资料,得知google为了更好的利用本地cache,将Ctrl+F5的功能屏蔽。
3) 配置Cache-Control的max-age=0时的浏览器响应
结论:通过上表数据可以得出,Firefox在redirect的情况下,它会发送一public或Private的Cache-Control给服务器端,同时IE及Chrome都会以一个max-age=0的Cache-Control的标志给服务器,此时的Chrome浏览器Ctrl+F5没有发送no-cache,而是max-age=0。










