你完全不用耐心的看完后面所有的说明，awstats在进行日志统计时，
命令行统计增加： -databasebreak=day
报表输出时增加： &databasebreak=day&day=DD
即可按天进行统计, 解决按月统计，归档数据过大导致统计过慢/失败的问题。
问题：
很
多网站在流量从10万级增加到百万级以后就放弃了awstats作为统计，具体表现就是到月底的时候，统计数据会运行1天都运行不完。于是就改为
webalizer或者analog了。其实这并非awstats统计效率不高：awstats很多丰富的统计指标：蜘蛛识别
浏览器识别，文件类型统计等，都是比Webalizer丰富的，Webalizer要实现类似的统计力度也会出现性能问题。
原因分析：
性
能的瓶颈在哪里呢：awstats统计缺省时按月统计，到月底时候记住的头20多天的历史IP等累计统计指标，会使得DUMP数据文件变得很大（数百
M），而awstats运行时，需要的内存量是dump数据文件的3－4倍。当这个monthly积累的数据导致awstats统计脚本载入内存的数据量
过大，用到系统文件交换做内存的时候日志统计效率就会降低了（处理速度会低2-3个数量级），于是出现了运行一天都统计不完前一天日志的现象。
解决：
AWStats丰富的统计指标还是很有用的，而一个网站已经达到日千万级的访问请求，按天的详细的数据统计也是必须的了。所以：索性牺牲一下按月的独立IP统计，将日志改成按天统计，如果需要按月的汇总，可以利用awstats的dump数据成为一个中间数据源汇总统计。
其他问题：
1 按天的报表浏览：用Calendar.php做个日历浏览界面；
按
天统计后，awstats的输出文件会变成awstatsMMYYYYDD.confname.txt 每天一个统计文件，而报表的输出需要增加
&databasebreak=day&day=DD
来指定某一天的数据。增加了日期后，awstats的报表输出有些不方便，awstats本身没有提供按日的浏览，可以自己做个日历前端，方便awstats的报表浏览。
2 日志数据源：最好是压缩的，因为日志上2G以后，文件系统出问题的可能性大。尽量还是压缩日志后，通过zcat管道给awstats进行统计；
类似的思路：
1 如果 databasebreak=day 仍然无法解决问题， 排除掉次要统计指标：过滤掉图片 js css等文件的请求日志；
2 如果仍然没有办法解决问题： 设置为小时级别截断 databasebreak=hour 然后用每天的同一个小时（比如：下午5点－6点）做为1天的抽样，进行每天的数据跟踪；
总之：为了统计精度/完整性牺牲重要的统计统计指标是不值得的。当流量提高到百万级别，即使损失了n%的精度，对于做出结论已经足够了。而且利用awstats 的dump data作为中间处理结果，进行数据挖掘也是很方便的（大部分是CSV，分项的很容易用grep截取分离出来）。
作者：车东 发表于：2007-03-07 21:03 最后更新于：2007-12-19 09:12
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明。
