828华为云征文 | 利用FIO工具测试Flexus云服务器X实例存储性能

news/2024/12/22 10:51:16/

目录

一、Flexus云服务器X实例概要

1.1 Flexus云服务器X实例摘要

1.2 产品特点

1.3 存储方面性能

1.4 测评服务器规格

二、FIO工具

2.1 安装部署FIO

2.2 主要性能指标概要

三、进行压测

3.1 测试全盘随机读IO延迟

3.2 测试全盘随机写IO延迟

3.3 测试随机读IOPS

3.4 测试随机写IOPS


一、Flexus云服务器X实例概要

Flexus云服务器X实例是华为云推出的一款面向中小企业和开发者的柔性算力云服务器。这款服务器的主要特点是其灵活的vCPU内存配比,支持热变配不中断业务变更规格,以及能够智能感知业务负载并自动调整资源配置,如下图。

1.1 Flexus云服务器X实例摘要

Flexus云服务器X实例的设计理念是提供一个更加灵活和高效的计算资源管理方式。其通过智能调整资源配置,能够更好地满足不同业务的需求,提高资源利用率。此外,该实例还提供了丰富的公共镜像供用户选择,方便快速部署各种应用和服务。用户还可以根据自己的需要灵活调整虚拟CPU和内存的配比,以满足不同场景的需求。

1.2 产品特点

除了之前提到的灵活的vCPU内存配比、支持热变配、智能感知业务负载以及出色的存储性能外,Flexus云服务器X实例的产品特点还包括以下几个方面:

  1. 高性能与成本优化
    • Flexus X实例通过X-Turbo加速技术,实现了性能上的显著提升,为用户带来了倍增的性能体验。
    • 该实例提供了经济型的价格和近乎旗舰级的性能,实现了跃级体验,同时降低了算力成本。
  2. 广泛的应用场景
    • Flexus X实例覆盖了高科技、零售、金融、游戏等多个行业的大多数通用工作负载场景,包括网络应用、数据库、虚拟桌面、分析索引、微服务、CI/CD等。
    • 它能够满足多样化的业务需求,为中小企业和开发者提供即开即用、超快部署的云计算解决方案。
  3. 安全性与可靠性
    • Flexus X实例拥有华为云旗舰级云服务器产品相同的单AZ 99.975%可用性,跨AZ 99.995%可用性,确保了服务的高可靠性。
    • 该实例还提供了智能识别和全面的安全防护技术,确保提供智能化且安全的云服务。
  4. 易用性与维护性
    • Flexus X实例内置了丰富的解决方案与镜像,支持零门槛快速搭建业务环境,轻松启动和管理业务。
    • 用户可以通过简单的配置和购买流程,快速上手并使用该实例。
  5. 灵活的计费模式
    • Flexus X实例支持包年/包月和按需计费等多种计费模式,用户可以根据自己的业务需求选择合适的计费方式。

官网如下图:

1.3 存储方面性能

Flexus云服务器X实例在存储方面表现出色。它支持多种存储类型,包括系统盘和数据盘,且系统盘为通用型SSD,确保了数据读写的高速性和稳定性。用户可以根据自己的业务需求选择合适的存储类型和容量。此外,该实例还支持快照和备份功能,确保数据的安全性和可恢复性。在数据处理和存储方面,Flexus云服务器X实例满足了现代企业对高性能和高可靠性的要求。

Flexus云服务器X实例以其灵活的资源配置、高效的计算性能和可靠的存储能力,成为了中小企业和开发者的优选云服务器产品。

接下来,我们就利用FIO工具来测试一下Flexus云服务器X实例在存储方面的性能怎么样,主要从IOPS,IO延迟、IOPS和吞吐量等方面进行测试。

1.4 测评服务器规格

序号规格名规格参数
1实例名称flexusx-154d
2区域华北-北京四
3可用区可用区7
4vCPUs4核
5内存(GiB)12G
6系统盘通用型SSD(100G)
7镜像CentOS 7.5 64bit
8操作系统类型Linux
9带宽类型独享
10带宽大小3Mbit/s

二、FIO工具

FIO(Flexible I/O Tester)是一款开源的磁盘I/O性能测试工具,旨在提供一种全方面的测试方案,能够模拟常见的I/O场景,并记录和评估存储系统(如硬盘、固态硬盘、网络存储等)在不同负载条件下的输入/输出(I/O)性能。该工具广泛应用于标准测试、QA(质量保证)、验证测试等领域,并支持多种操作系统,如Linux、FreeBSD、NetBSD、OS X、OpenSolaris、AIX、HP-UX、Windows等。对于存储性能的测试,首选就是FIO。在本次测评中测试示例均使用fio jobfile方式,即通过一个job文件来描述待访真的IO负载,一个job文件可以控制产生任意数目的线程和文件,典型的job文件包含一个global段(定义共享参数)和一个或多少job段(描述具体要产生的job)。

2.1 安装部署FIO

其下载地址:https://brick.kernel.dk/snaps/fio-2.1.10.tar.gz

或者登录其官网:http://freshmeat.sourceforge.net/projects/fio/ 进行下载。但是官网很难找得到入口在哪,还是直接访问第一个链接就可以下载了。

接下来我们上传到服务器中,还是老规矩,我们使用cloudshell远程登陆我们的服务器。接下来我们将刚刚下载的FIO压缩包上传到服务器的opt目录下:如下图所示:

OK ,我们输入ls命令看看是否上传成功。

可以看得到,我们的安装包已经上传进去了,右侧文件管理器也有该压缩包。接下来我们解压安装:

执行以下命令解压缩安装包到我们的/usr/local目录下:

tar -zxvf fio-2.1.10.tar.gz -C /usr/local

注意:这里最好是先安装好下面两个依赖再执行,上面的安装命令,这里我忘记了,因此还要重新编译fio 

按顺序执行以下命令进行安装:

cd /usr/local/fio-2.1.10

./configure

make

make install 

OK,到这里我们就基本安装完成了,然后使用fio -v命令查看一下版本看看是否安装好:

因为fio还需要libaio依赖,然后依次执行以下命令,安装libaio:

sudo yum -y install libaio

sudo yum -y install libaio-devel

注意:这里最好是先安装好上面两个依赖再执行,上面的安装命令,这里我忘记了,因此还要重新编译fio 

可以看到我们已经安装好了。 

2.2 主要性能指标概要

下列这些都是服务器关于存储性能的相关指标

  1. IOPS(Input/Output Operations Per Second)
    • 定义:每秒的输入输出操作次数,是衡量存储设备性能的重要指标之一。
    • 重要性:IOPS越高,表示存储设备在单位时间内能够处理的I/O操作越多,性能越好。
  2. 吞吐量(Throughput)
    • 定义:存储设备在单位时间内传输的数据量。
    • 重要性:吞吐量越大,表示存储设备的数据传输速度越快,性能越好。
  3. 延迟(Latency)
    • 定义:I/O操作的响应时间,即从发出I/O请求到接收到响应的时间。
    • 重要性:延迟越小,表示存储设备的响应速度越快,用户体验越好。
  4. CPU利用率
    • 定义:在执行I/O操作时,CPU的使用率。
    • 重要性:CPU利用率反映了I/O操作对系统资源的占用情况,过高的CPU利用率可能导致系统性能下降。
  5. I/O深度
    • 定义:并发发出的I/O请求数,也称为队列深度。
    • 重要性:I/O深度越大,表示存储设备能够同时处理的I/O请求越多,可能提高系统的吞吐量。
  6. 读写块大小
    • 定义:每次I/O操作传输的数据块大小。
    • 重要性:读写块大小对存储设备的性能有显著影响,不同的块大小可能导致不同的IOPS和吞吐量。

三、进行压测

不过在测试之前,我们需要执行以下命令查看存储设备是否已经4KiB对齐。如果不是4KiB对齐,则对性能影响较大。
fdisk -lu
如果返回的Start值能够被8整除则表示4KiB对齐。

可以看得到,我们这里的start值为2048,2048%4 = 0是合适的。 

执行以下命令,切换路径。
cd /tmp

3.1 测试全盘随机读IO延迟

创建job_file文件测试随机读的IO延迟,文件内容如下。创建后,执行命令fio job_file查看测试结果。

[global]
ioengine=libaio
userspace_reap
runtime=60
direct=1
group_reporting
randrepeat=0
norandommap
ramp_time=6
iodepth=1
numjobs=1
exitall
[randread4k]
filename=/dev/vda1
rw=randread
bs=4K

这个测试结果是通过 fio 工具进行的随机读取测试,具体是针对4KB大小的块进行的。以下是对测试结果的详细解读:

性能指标

  • 总读取量:1222.1MB
  • 带宽:20870KB/s(平均)
  • IOPS:5217(每秒输入输出操作数)

延迟统计

  • 服务时间(slat):平均2.93微秒,标准差1.08微秒
  • 完成时间(clat):平均188.30微秒,标准差129.33微秒
  • 总延迟(lat):平均191.30微秒,标准差129.34微秒
  • 完成时间百分位数
    • 1%:137微秒
    • 5%:143微秒
    • 10%:149微秒
    • ...
    • 99.99%:5088微秒(即5.088毫秒)

带宽分布

  • 最小带宽:0KB/s
  • 最大带宽:22184KB/s
  • 99.25%的时间内,带宽在20712.93KB/s左右

延迟分布

  • 250微秒以内:89.49%
  • 500微秒以内:99.46%(包括250微秒以内的)
  • 1毫秒以内:99.60%(包括500微秒以内的)
  • 2毫秒以内:99.73%(包括1毫秒以内的)
  • ...

CPU使用情况

  • 用户态CPU使用率:0.92%
  • 系统态CPU使用率:3.05%

IO深度与提交/完成状态

  • 所有IO操作都在IO深度为1时完成
  • 提交和完成操作都集中在4个块大小(即16KB)的批次上

磁盘统计

  • vda(虚拟磁盘设备):
    • 读取IO操作数:343976
    • 写入IO操作数:43(很少,可能是元数据或后台操作)
    • 合并读取操作:0(没有合并)
    • 合并写入操作:29(有一些合并)
    • 队列中时间:64388个ticks(表示磁盘忙碌程度)
    • 磁盘利用率:99.90%

总结

这个测试结果表明,在随机读取4KB块的情况下,系统能够达到约20870KB/s的带宽和5217 IOPS的性能。延迟方面,大部分读取操作在250微秒以内完成,99.99%的读取操作在5毫秒以内完成。CPU使用率相对较低,表明测试期间CPU不是瓶颈。磁盘利用率非常高,接近100%,说明磁盘在测试期间几乎一直在忙碌。

3.2 测试全盘随机写IO延迟

创建job_file文件测试随机读的IO延迟,文件内容如下。创建后,执行命令fio job_file查看测试结果。

[global]

ioengine=libaio

userspace_reap

time_based runtime=60

direct=1

group_reporting randrepeat=0

norandommap ramp_time=6

iodepth=1

numjobs=1

exitall

[randwrite4k]

filename=/dev/vda1

rw=randwrite bs=4K

 下面就是上述结果的解读:

  • 总体性能指标

    • 总写入数据量:429932KB(约420MB)
    • 平均带宽:7165.5KB/s(或约7.17MB/s)
    • 每秒I/O操作次数(IOPS):1791
    • 运行时间:60001毫秒(60秒)
  • 提交时延(slat)

    • 最小值:2微秒
    • 最大值:52微秒
    • 平均值:4.73微秒
    • 标准差:1.86微秒
    • 提交时延主要由服务器处理器和操作系统决定,也受SSD的接口协议和工作模式影响。在这个测试中,提交时延非常低且稳定。
  • 完成时延(clat)

    • 最小值:319微秒
    • 最大值:123271微秒(即123.271毫秒)
    • 平均值:552.69微秒
    • 标准差:765.64微秒
    • 完成时延主要由SSD决定,反映了从I/O提交到I/O完成的时长。在这个测试中,完成时延的波动较大,但平均值仍在可接受范围内。
  • 总时延(lat)

    • 最小值:324微秒
    • 最大值:123275微秒(即123.275毫秒)
    • 平均值:557.54微秒
    • 标准差:765.64微秒
    • 总时延是提交时延和完成时延之和,反映了从fio创建I/O到I/O完成的时长。
  • 最小带宽:0KB/s(测试开始时)
  • 最大带宽:7880KB/s
  • 带宽利用率:99.24%
  • 平均带宽:7110.49KB/s(与平均带宽指标略有差异,但相差不大)
  • 标准差:778.76KB/s
  • CPU使用率

    • 用户态:0.30%
    • 系统态:1.76%
    • 上下文切换次数:117896次
    • CPU使用率较低,表明测试对CPU资源的消耗不大。
  • I/O深度

    • I/O深度为1时,占比为109.7%(超过100%可能是因为四舍五入或并发I/O请求数略有波动)
    • 其他I/O深度(2、4、8、16、32、>=64)的占比均为0%
    • 这表明测试期间主要使用的是I/O深度为1的并发I/O请求。
  • 磁盘I/O操作数

    • 读操作数:305次
    • 写操作数:117792次
    • 合并读操作数:0次
    • 合并写操作数:33次
    • 磁盘主要忙于写操作。
  • 磁盘忙碌时间

    • 读操作忙碌时间:258个ticks
    • 写操作忙碌时间:64950个ticks
    • 队列中等待时间:65208个ticks
    • 磁盘利用率:99.88%
    • 磁盘在测试期间几乎一直处于忙碌状态。

这份fio测试结果表明,存储系统在执行4KB大小的随机写入操作时表现出良好的性能。尽管完成时延存在一定的波动,但平均带宽和IOPS均保持在较高水平。同时,CPU使用率较低,磁盘利用率较高,表明测试期间存储系统得到了充分的利用。

3.3 测试随机读IOPS

创建job_file文件测试随机读的IOPS,文件内容如下。创建后,执行命令fio job_file查看测试结果。

[global]
ioengine=libaio
userspace_reap
time_based
runtime=60
direct=1
group_reporting
randrepeat=0
norandommap
ramp_time=6
iodepth=128
numjobs=8
exitall
[randread4k]
filename=/dev/vda1
rw=randread
bs=4k

这份fio测试结果提供了关于存储系统在执行4KB大小的随机读取操作时的详细性能数据。以下是对测试结果的详细解读:

总体性能指标

  • 总读取数据量:1888.5MB
  • 平均带宽:32227KB/s(或约32.23MB/s)
  • 每秒I/O操作次数(IOPS):8039
  • 运行时间:60003毫秒(60秒)

时延分析

  • 提交时延(slat)
    • 最小值:2微秒
    • 最大值:975348微秒(即0.975秒)
    • 平均值:830.63微秒
    • 标准差:27773.96微秒
    • 提交时延的波动较大,但平均值仍在可接受范围内。这可能是由于系统负载、中断处理等因素导致的。
  • 完成时延(clat)
    • 最小值:285微秒
    • 最大值:1001.5K微秒(即1001.5毫秒或1秒)
    • 平均值:128273.66微秒(即128.27毫秒)
    • 标准差:323745.43微秒
    • 完成时延的波动非常大,且平均值较高。这表明存储系统在处理随机读取请求时存在较大的延迟。
  • 总时延(lat)
    • 最小值:288微秒
    • 最大值:1001.5K微秒(即1001.5毫秒或1秒)
    • 平均值:129126.08微秒(即129.13毫秒)
    • 标准差:324666.03微秒
    • 总时延的波动和平均值都与完成时延相似,因为完成时延在总时延中占主导地位。

此外,测试还提供了时延的百分位数数据。例如,99.99%的I/O操作在987136微秒(即0.987毫秒)内完成,但需要注意的是,这里的99.99%百分位数实际上受到了极端值的影响,因为大部分操作的完成时延都远低于这个值。

带宽分析

  • 最小带宽:0KB/s(测试开始时)
  • 最大带宽:9719KB/s
  • 带宽利用率和平均值等数据在测试报告中未直接给出百分比形式,但可以通过计算得出。例如,平均带宽为3935.28KB/s(在多个并发I/O请求下测得),这表明存储系统在测试期间能够提供稳定的带宽输出。然而,与平均带宽32227KB/s(整体测试的平均值)相比,单个请求的带宽波动较大。

磁盘统计信息

  • 磁盘I/O操作数
    • 读操作数:536101次
    • 写操作数:48次(几乎可以忽略不计)
    • 磁盘主要忙于读操作。
  • 磁盘合并操作数
    • 读操作合并数:0次(表明读操作没有被合并)
    • 写操作合并数:37次(但写操作次数很少,所以合并操作的影响不大,因为这里我们主要测试的是随机读情况下的IOPS)
  • 磁盘忙碌时间
    • 读操作忙碌时间:31904414个ticks(表明磁盘在测试期间几乎一直处于忙碌状态)
    • 写操作忙碌时间:1244个ticks(很少)
    • 队列中等待时间:31905658个ticks(与读操作忙碌时间相近)
    • 磁盘利用率:93.49%(表明磁盘在测试期间得到了充分的利用)

这份fio测试结果表明,存储系统在执行4KB大小的随机读取操作时,虽然能够提供较高的平均带宽和IOPS,但完成时延的波动较大且平均值较高。但是这可能是由于存储系统的内部机制、磁盘性能或系统负载等因素导致的。为了改善性能,可以考虑优化存储系统的配置、升级硬件或降低系统负载等方法。同时,进行更多类型的测试(如顺序读、混合读写等)并分析测试结果也是很有必要的。 但整体下面我们主要测试的是随机读的情况下。

3.4 测试随机写IOPS

创建job_file文件测试随机写的IOPS,文件内容如下。创建后,执行命令fio job_file查看测试结果。

[global]
ioengine=libaio
userspace_reap
time_based
runtime=60
direct=1
group_reporting
randrepeat=0
norandommap
ramp_time=6
iodepth=128
numjobs=8
exitall
[randwrite4k]
filename=/dev/vda1
rw=randwrite
bs=4k

这份fio测试结果提供了关于存储系统在执行4KB大小的随机写入操作时的详细性能数据。以下是对测试结果的解读:

总体性能指标

  • 总写入数据量:1883.8MB
  • 平均带宽:32147KB/s(或约32.15MB/s)
  • 每秒I/O操作次数(IOPS):8019
  • 运行时间:60003毫秒(60秒)

时延分析

  • 提交时延(slat)
    • 最小值:2微秒
    • 最大值:974711微秒(即0.975秒)
    • 平均值:807.85微秒
    • 标准差:27292.34微秒
    • 提交时延的波动较大,但平均值在可接受范围内,表明系统处理I/O请求的中断和调度效率尚可。
  • 完成时延(clat)
    • 最小值:481微秒
    • 最大值:1011.9K微秒(即1011.9毫秒或1秒多)
    • 平均值:128600.31微秒(即128.6毫秒)
    • 标准差:322867.92微秒
    • 完成时延的波动非常大,且平均值较高。这表明存储系统在处理随机写入请求时存在较大的延迟,可能是由于磁盘性能瓶颈、存储系统内部处理机制或系统负载等因素导致的。
  • 总时延(lat)
    • 最小值:484微秒
    • 最大值:1011.9K微秒(即1011.9毫秒或1秒多)
    • 平均值:129420.85微秒(即129.42毫秒)
    • 标准差:323748.74微秒
    • 总时延的波动和平均值与完成时延相似,因为完成时延在总时延中占主导地位。

此外,测试还提供了时延的百分位数数据。例如,99.99%的I/O操作在995328微秒(即0.995毫秒)内完成,但需要注意的是,这里的99.99%百分位数实际上受到了极端值的影响,因为大部分操作的完成时延都远低于这个值。

带宽分析

  • 最小带宽:0KB/s(测试开始时)
  • 最大带宽:9237KB/s
  • 平均带宽利用率和值等数据表明,存储系统在测试期间能够提供稳定的带宽输出,但单个请求的带宽波动较大。

CPU和I/O深度

  • CPU使用率
    • 用户态:0.08%
    • 系统态:0.56%
    • CPU使用率非常低,表明测试对CPU资源的消耗很小。
  • I/O深度
    • 在测试期间,主要使用的是I/O深度大于等于64的并发I/O请求(占比111.6%,超过100%可能是因为四舍五入或并发I/O请求数略有波动)。
    • 提交和完成I/O请求时,主要使用的是4KB大小的块(占比100%)。

磁盘统计信息

  • 磁盘I/O操作数
    • 读操作数:375次(很少,因为主要是写入测试)
    • 写操作数:535818次
    • 磁盘主要忙于写操作。
  • 磁盘合并操作数
    • 读操作合并数:0次
    • 写操作合并数:41次(写操作合并次数相对较多,但考虑到写操作总数很大,合并比例仍然很低,因为我们这里主要是测试随机写的IOPS)
  • 磁盘忙碌时间
    • 读操作忙碌时间:21348个ticks(很少)
    • 写操作忙碌时间:32530818个ticks(表明磁盘在测试期间几乎一直处于忙碌状态)
    • 队列中等待时间:32552166个ticks(与写操作忙碌时间相近)
    • 磁盘利用率:90.91%(表明磁盘在测试期间得到了充分的利用)

综上所述,这份fio测试结果表明,存储系统在执行4KB大小的随机写入操作时,虽然能够提供较高的平均带宽和IOPS,但完成时延的波动较大且平均值较高。这可能是由于存储系统的内部机制、磁盘性能或系统负载等因素导致的。为了改善性能,可以考虑优化存储系统的配置、升级硬件(如使用更快的SSD)、调整I/O调度策略或降低系统负载等方法。同时,进行更多类型的测试(如顺序写、混合读写等)并分析测试结果也是很有必要的。

整体感觉来说,还是非常不错的,带宽方面也可以提供稳定输出,且磁盘的随机读写性能都非常好。

结合上面测评来说,华为云Flexus云服务器X实例以其柔性算力、高性能加速、成本优化和安全可靠等特点,成为中小企业在828企业节期间选择云服务的优选之一。如果您正在寻找一款性价比高、性能卓越的云服务器产品,不妨考虑华为云Flexus云服务器X实例。点击下方卡片立即跳转查看吧:

Flexus云服务器X实例-华为云Flexus云服务器X实例(Flexus X)是柔性算力,六倍性能,旗舰体验,覆盖高科技、零售、金融、游戏等行业大多数通用工作负载场景。icon-default.png?t=O83Ahttps://www.huaweicloud.com/product/flexus-x.html


http://www.ppmy.cn/news/1534343.html

相关文章

掌控物体运动艺术:图扑 Easing 函数实践应用

现如今,前端开发除了构建功能性的网站和应用程序外,还需要创建具有吸引力且尤为流畅交互的用户界面,其中动画技术在其中发挥着至关重要的作用。在数字孪生领域,动画的应用显得尤为重要。数字孪生技术通过精确模拟现实世界中的对象…

iOS--RunLoop原理

前言 曾经在写项目的时候遇到过这么一个问题。: 项目中添加了一个tableview,然后还有一个计时器,当滑动tableview的时候会阻塞计时器,你得执行这么一段代码后,计时器才能正常运行。 RunLoop.current.add(timer, for…

游戏中的对象池技术探索(一)

前言 对象池技术在游戏开发中的应用非常普遍,它是一种高效管理对象实例的技术,能够避免频繁和重复创建对象所带来的性能开销。本篇文章我们就来探索一下如何在游戏开发中设计通用对象池,使之易于使用和扩展。 代码 代码目录结构 ObjectPool …

第三章 Redis常用五大数据类型之String

目录 一、介绍 二、常用命令 2.1. set ​2.2. mset 2.3. get 2.4. getset 2.5. mget 2.6. setnx 2.7. setex 2.8. msetnx 2.9. append 2.10. strlen ​2.11. incr 2.12. decr 2.13. incrby/decrby 2.14. getrange 2.15. setrange 2.16. keys 2.17. exists …

(c#)unity中sqlite多线程同时开启事务会导致非常慢

在程序使用sqlite后,变慢了4秒.看看插入量,并不多,还开了事务,怎么都不可能卡上4秒.测了好久才发现,多线程一起开事务就变成单线程了. 其实原先我就看到了这个说法,还测试过.当时测试发现速度很快,没受影响.我误以为是只有提交事务时才变单线程.原来是因为当时多线程使用的是同…

2024年7月大众点评天津美食店铺基础信息

在做一些城市分析、学术研究分析、商业选址、商业布局分析等数据分析挖掘时,大众点评的数据参考价值非常大,截至2024年7月,大众点评美食店铺剔除了暂停营业、停止营业后的最新数据情况分析如下。 天津餐饮美食店铺约8.6万家,有均…

【算法竞赛】尺取法

尺取法(又称为双指针、Two Pointers)是算法竞赛中一个常)用的优化技巧,用来解决序列的区间问题,操作简单,容易编程。如果区间是单调的,也常常用二分法求解,所以很多问题用尺取法和二分法都行。另外,尺取法的操作过程和分治算法的步骤很相似,有时也用在分治中。 概念 什么是尺…

Splashtop 加入 Microsoft 智能安全协会

2024年9月25日 美国加利福尼亚州库比蒂诺 Splashtop Inc . 今天宣布已正式加入 Microsoft 智能安全协会(MISA)。MISA 由独立软件供应商(ISV)和托管安全服务提供商(MISA)组成,他们将其解决方案与…