您好，之前我们收集了更多的维度，后面在实际应用中一点点精简到52维，也是一个通过大量数据不断尝试分析的过程。两层分类模型也是我们后期优化的，为了增加识别的精度，最初就是直接分析出瓶颈点，具体可以看下我们的历史代码。Analysis可以指定具体的采集次数，collection可以指定具体的采集数据间隔时间、采集总时间，这些都是为了适配不同的场景做的自定义项，因为不同的应用场景负载变化情况不一样，总的来说采集的数据越多越好，至少要保证一个应用场景运行的整个周期。

发件人: 胡迪 [mailto:hudi2011@163.com]
发送时间: 2021年8月26日 18:15
收件人: hanxinke <hanxinke@huawei.com>
抄送: a-tune@openeuler.org; Fanwentao (Henry) <fanwentao@huawei.com>
主题: 回复：[A-tune] 答复: A-Tune问题请教

您好，感谢您的回答。
问题2: 看到是52维的特征，那这些特征的选取有什么考量没？第一层是分出来default 还是 throughput, 第一层为啥不分出来具体的瓶颈，比如是cpu 还是 memory, 或者cpu &memory。此外analysis 可以指定收集时间，那么收集时间的设定主要考量什么呢？
感谢您不吝赐教。

	胡迪
邮箱：hudi2011@163.com

签名由 网易邮箱大师 定制

在2021年08月25日 15:25，hanxinke 写道：

您好，感谢您对A-Tune的支持。

问题1：grpc是一种rpc技术，但是rest并不算一种rpc技术，使用rest的原因是A-Tune中的一些调优算法以及数据采集部分是用python来实现的，因此存在go调用python的场景，使用rest的好处是接口调用中并不需要感知服务端定义的具体方法，使用POST/GET/PUT接口就可以完成调用，扩展性比较强，而rpc需要客户端和服务端提供一致的序列化协议，且要求客户端接口与服务端接口保持一致。当然两者都可以实现对应的功能，而且grpc在传输效率上更高，只是在我们这个场景下一次算法调用得到一次结果，并不需要高并发，使用rest更简单。

问题2：针对系统中不存在的场景识别为系统已经存在场景的情况，可以认为他们两者存在类似的负载，使用相同的profile会有性能提升。同时也可以使用我们的离线调优工具atune-adm tuning进行参数调优，并将调优结果和采集的数据集加到A-Tune仓作为一种新的类型。当前建模方法就是对这些瓶颈点的识别和建模，我们这边采集了32维数据作为输入，输出分类模型。

发件人: 胡迪 [mailto:hudi2011@163.com]
发送时间: 2021年8月25日 10:57
收件人: a-tune@openeuler.org
主题: [A-tune] A-Tune问题请教

您好：

对于A-Tune 的代码有2个问题请教：

                1. A-Tune 中使用了gRPC 和 RESTful api 两种RPC 技术， 请问使用RESTful api 是基于怎样的考量，为什么不就用gRPC 一种技术？

                2. 在线静态调优在对负载进行识别时， 如果负载为speccpu2017 , 识别结果是speccpu2006, 那么我们是认为speccpu2017 也可以按照speccpu2006 的profile 一样来设置，也会有提高。还是应该认为speccpu2017 是一种新的负载，属于自定义模型。如果把这个分类问题抽象为对瓶颈的识别，比如识别CPU，memory, disk, network 四个方面，一共15种瓶颈的组合。目前的建模方法相对于直接对瓶颈进行建模的思路，主要的考量是什么呢？

Best Regards

TimHu