您好，感谢您对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