Progress Report 2018.05.13

1.用sleep模拟workload有一个问题：目前看到的workload大都是导致了代码中某个循环执行的次数多，或者干的事情太多了（GCC-46401、Firefox-490742、Mozilla-515287、httpd-54852、Mysql-33948），因为单独一条语句因为workload大而缓慢的bug没有见到。我做实验用了一下Profile工具gprof。这个工具还有问题，就是不能把所有执行到的函数都记录下来，因为一个我确信执行了的代码它没记录（可能是我操作不对），但是光人工看就能发现光是简单插sleep的问题在哪里，例如：

待测代码:

#!c++
bar(){
   ...
   while(condition1) // 大负载下会多次循环
   {
      foo()
   }
   ...
}

插入sleep：

#!c++
bar(){
   ...
   sleep(sometime)
   while(condition1) // 大负载下会多次循环
   {
      foo()
   }
   ...
}

插入sleep的目的是为了使得在小负载下得到与大负载下相同的profile。但是按照上面的插入sleep的方法，得到的profile也许能做到bar时间一样，但是foo的时间一样但次数不一样，不能真实地模拟；但是如果在foo()里面插入sleep也许也能做到bar的时间一样，但是一个是foo的次数多时间短，另一个是foo的次数少时间长，也不能模拟。 那么能不能想办法让循环次数变多呢？也是不太行的。因为有些循环是自然变多的，不是用一个数字控制的，不是就调一个参数那么简单。

2.一开始我是想：性能关于配置的分布有没有一些‘突变’‘不正常’的点，比如随着配置值变大，到一个临界值的时候性能突然暴增。但是实际bug不一定都有这个临界值，更多的没有突变点，可能就是一条正常的曲线。那么我们能不能这样考虑，我只考虑在软件演化中新引入的性能bug，把当前待测版本的性能对配置的分布与上一版本作对比，如果比上一版本在某个配置值处明显（用假设检验来定义明显）慢了，就认为是引入了一个新的性能bug，也就是性能回归测试。然后我就看了一下现在看的这20来个bug，还真有几个是report中明确表达是前面版本速度正常而新版本慢了，有些没有明确，可能需要人工验证一下。这个方法就使测试有了一个‘基准’，一定程度上回避了缺少test oracle的问题。

3.阅读paper-Performance Debugging in the Large via Mining Millions of Stack Traces ICSE'12 微软亚洲研究院

这篇文章是用stack trace（用户提供，确定有性能问题）分析微软软件的性能问题的代码，使用了机器学习方法，因为他们数据非常多，所以不需要担心样本不足的问题。解决了很实际的三个问题:1.stack trace中有带有性能问题的trace、有正常的trace，如何摘除正常的留下带问题的。（这里面正常的主要指同样花时间比较多但不是bug，比如等待用户输入、等待其他任务完成。因此作者构建了一个等待模型，来提取stacktrace中运行慢而不是等待久的部分）2.stack trace往往很长，哪些是有用的，哪些是冗余的。（频繁子序列方法）3.同一个性能bug在不同环境中的stacktrace可能有微小差异，如何处理。这篇文章解决的challenge就是当时没有一个很好的性能debug工具，而作者团队做出了一个，而且比较管用。（The first formulation and real-world deployment）。

4.完成mariadb的log补全工作，开始cubird的补全。结果

我发现需要补全log的，也就是用户不报log的，很多bug是因为软件的结果没有满足用户的预期，比如用户想得到一个1.23，结果得到了1.2，这种bug的日志我不确定是否有用，因为可能就是一串note,连个warning都没有。