一个典型的性能分析案例

知识星球一位同学问了这样一个性能问题：

需求场景：车端上传触发类信号数据到TOS桶，持续1分钟会产生1G左右的包，但不是每分钟都会传。然后云服务Kafka监听到数据产生，处理这些数据。

测试方式：等比例准备20T数据，按单位时间的量，从桶间复制到监听的桶来模拟并发。

问题一：车多了以后同时上传数据，如何确认公有云桶吞吐性能？如果这里有瓶颈怎么处理？

问题二：如果同时模拟大批量用户(1000)在2小时内上传巨量数据(20T)，这种场景怎么做？带宽费用如何计算？

这个问题可以说描述的比较全面了，有场景有具体数据还有明确的问题方向。有了这些信息之后，我们对这个案例展开分析，看看如何解决上述的两个问题。

 

首先，分析问题之前先尝试把服务请求和调用关系绘制出来，如下图：

简单理解该场景，即车辆端(可以理解为本地)产生信号数据时，会上传到云端TOS桶进行存储。Kafka会监听TOS是否有新数据产生，如果有则拉取对应数据，进行对应处理。

这里简单介绍下TOS。TOS，意为顶级的对象存储(Top Object Storage)，它是一款分布式存储产品。

区别于传统的文件存储系统是多层级树形目录结构，TOS采用的是扁平化存储方式，即桶内所有对象都处于统一逻辑层级。其中：

• 存储桶：存储桶(bucket)是用户存储对象(Object)的容器。
• 对象：对象(Object)是TOS存储数据的基本单元对象由键(Key)，数据(Data)和元数据(Metadata)三部分组成。

• key：对象名，类似MAP的key。
• Data：对象内容，是存储主题。
• MetaData：对象的元数据，如对象大小、类型。

PS：图源于网络，侵删。

 

问题一：车多了以后同时上传数据，如何确认公有云桶吞吐性能？如果这里有瓶颈怎么处理？

这个问题其实在我看来是很简单的，因为数据存储采用的是云服务，即第三方厂商提供的服务。

类似云服务这种产品，相对来说都是比较标准化的，且TOS这种分布式的存储服务，都是支持水平扩展的，因此不必太过担心它的性能瓶颈。

假如该产品真出现所谓的性能瓶颈，大概率是采购规格问题，即购买的TOS服务本身的产品设计如此。如下图：

PS：图源于火山引擎TOS产品文档，侵删。

当然，不能将自己服务的可靠性全部交给云服务，因此在这个问题上，要考虑自己服务范围内的场景，即车端上传TOS这部分的带宽和流量大小。

在这点，要考虑真实的用户场景中，日常和极限场景下，单位时间内的数据产生量，对此进行一定的冗余处理即可。

 

问题二：如果同时模拟大批量用户(1000)在2小时内上传巨量数据(20T)，这种场景怎么做？带宽费用如何计算？

这个问题问到了如何做，其实就是性能测试场景设计和实施方面。下面是分析思路：

前置条件：数据上传是持续性的。

数据分析：1000用户在2小时内上传20T数据，平均每秒上传约2.84G的数据。

用户场景：车端(本地)上传数据，上传速率➗8，排除车端本身网络带宽限制，则TOS入口带宽需要达到22.72Gbps。

场景分析：如上都是按照平均值，且1个车端1分钟产生1G数据位前提进行计算的，但需要考虑具体场景。

比如：车端正常产生数据需要多少时间？极端场景产生数据会持续多长时间(极限阈值)？不同场景的所占比率各是多少(流量模型)？

数据准备：依据上述场景得到具体的流量模型分布，然后准备对应的测试数据(或按照场景自行预埋数据)。

带宽费用：按照火山引擎的文档说明，标准的服务带宽无法用户场景，解决方案有两种：

一种是提供单，由服务商配置专有网络通道(网络更稳定，但费用更高)；另一种则是车端数据上传前压缩，或者TOS入口限流(带宽费用较低，但需技术改造，会影响一定的时效性)。

 

补充说明：

1-从桶间复制数据到监听的桶模拟并发，取巧但不符合实际场景。

2-需求分析要按照实际场景，分段分场景讨论(如我是先梳理请求调用关系，再逐段分析)。

3-数据从TOS监听桶到kafka，同样需要考虑带宽传输速率，以及Kafka自身的容量(配置规格)。

 

如上就是我对这个性能需求案例的分析和思考，仅供大家参考。