Shell script运行时间相关

1. 

最近在研究在两种不同的场景下(分别是Unix Tools和Apache Flink),分析网络跟踪文件(例如,.pcap文件)性能的区别。最简单也是最直观的比较方法就是比较在这两种环境中,处理相同的.pcap文件所需要的时间长短。想着写个小脚本应该分分钟搞定,结果在计算时长的时候出现了问题:

#!/bin/bash

START_TIME=$(date +%s.%N)

do something 

END_TIME=$(date +%s.%N)

ELAPSED_TIME=$((END_TIME - START_TIME))

echo "Runtime: $ELAPSED_TIME seconds"

此时,会抛出Illegal number的错误! 查了一下Shell本身不支持浮点运算,需要借助一个小工具bc,如果manual page看起来比较烦的话,这个tutorial比较简单直观。总的来说大概用法就是:

result=$(echo “options; operation” | bc [options])

于是,ELAPSED_TIME=$((END_TIME - START_TIME))就变成了

ELAPSED_TIME=$(echo "$END_TIME - $START_TIME" | bc )

别忘了变量前的“$”。

2.

小脚本终于跑了起来,分析一个大小为1 GB的.pcap文件大约耗时10 sec,具体统计什么这里就不说了,也没啥用。然而以上都是我在OS X中的Linux虚拟机上搞定的,Apache Flink的环境之前是在OS X上搭建的,所以脚本还是要在OS X上跑才行,而且目前也不知道虚拟机的性能会不会对结论的分析有什么影响。总而言之就是我把脚本在OS X的终端里运行了一下,发生了一个事情——Illegal character: N

这真的让我不太能理解,意思就是date +%s.%N中的%N在OS X下是不支持的(到现在不明白是为什么)。StackExchange上也有类似的问题,于是在上面找到了一个取巧的解决办法:

python -c 'import time; print time.time()'

所以,

START_TIME=$(python -c 'import time; print time.time()')

对于END_TIME同理,问题解决。( 在测试的时候发现 echo "$START_TIME"精度很高,做过运算之后精度只保留到小数点后两位,不知道原因,明天研究下 。再次测试,发现是自己搞错了,python直接输出精度也为0.01s。)

3.

在OS X和Linux虚拟机中对同一个.pcap文件进行分析,OS X所用时间为20 sec左右,为Linux下的2倍,待研究。

你可能感兴趣的:(Shell script运行时间相关)