这些日志是自动写入的,每天会根据日期生成一个文件夹,文件夹中每个小时生成一个日志文档。脚本要做的就是便利24个文档,读取内容进行分析。
由于需要把24个文档在一起分析,所以同学一开始的思路是:
对每一个类型进行统计,每次统计都遍历所有文件明显效率不怎么样,但是实际上也够用了因为只要在服务器上让脚本跑起来,过几分钟回去看结果就行了
但是因为脚本要给别人看==,所以不能太难看,因此要重新写一下。
开始的脚本是shell脚本,我不太熟悉,所以用python重写了
思路就是定义一堆list变量用来记录ip,每读入一个ip就在list里面查找(not in),如果找不到就插进去。
最后统计list的长度
这样只需遍历一边文件就行了,但是……………………………………
不知道为啥,貌似python写完之后比原来还慢
后来同学一句话点破,not in 查找的时候需要对字符串进行匹配,而原来的shell脚本是用sort排序之后用unique进行去重统计,难怪这么慢。
于是考虑将ip字符串转换成long型再存储在list里面,这样匹配的时候是不是能快点?
但是结果好象还是不理想。在少量数据(两个日志文件)的时候,大概能比shell(8s)脚本慢几秒种(16s,是两倍左右),但是在大数据量的情况下就不容乐观了(多出1/3左右的时间)。
大量数据的情况下会慢几分钟==
不过貌似数据量越大差距越小,足够大的话游客能超过shell,但是差距还是太差了啊.
后来在网上查找了一下,发现原来字典的查找速度更快,因为字典在查找的时候使用hash。于是尝试把所有list换成字典。
果然效果神速。在两个文件的时候,2.9秒左右。既然hash了,那么将ip转化位long型也没有意义了反而做了无用工。去掉之后大概是2.7秒。
然后调整了匹配的顺序,将数量较多的类型先匹配,这样又快了一点点。
如此做一个总结:
1.python中list进行查找和去重的时候(in 操作),使用字符串的匹配,所以速度比较慢。如果存储的是整型则会快一些(数量多的时候还是很慢)。
2.字典使用哈希查找,因此速度很快。
3.调整匹配顺序也可在一定程度上优化速度。
没有评论:
发表评论