WorkStation的网络损耗


背景

对周六遇到的问题进行了一下深入思考.
发现虽然可以通过WorkStation的方式来进行Clients以及新命令的扩容.
但是Workstation的桥接网络模式的性能不清楚有多大的损耗. 为了房子性能出现巨大的衰退.
这边进行了一下简要的测试与验证.

结论

Windows物理机 本地进行测试和使用linux远程测试 3.2.100 的QPS 都在 24000 左右.
比较稳定, linux上面的测试结果甚至要比 Windows本地测试的要稍微高一点 但是 Windows 上面的 WorkStation虚拟机就就存在问题.
虚拟机内直接的测试结果是 35000左右
在虚拟机外部使用桥接网络测试的结果只有 10000多一点. 桥接网络导致redis的QPS只有实际值的三分之一, 也只有Windows 上面 3.2.100 的 一半.
感觉桥接网络导致了非常大的性能损耗.



在远程的测试结果

PING_INLINE: 10070.49 requests per second, p50=1.935 msec
PING_MBULK: 10324.18 requests per second, p50=1.903 msec
SET: 10163.63 requests per second, p50=1.943 msec
GET: 10234.37 requests per second, p50=1.919 msec
INCR: 10114.29 requests per second, p50=1.935 msec
LPUSH: 9981.04 requests per second, p50=1.951 msec
RPUSH: 9984.03 requests per second, p50=1.967 msec
LPOP: 4917.63 requests per second, p50=2.015 msec
RPOP: 10145.07 requests per second, p50=1.935 msec
SADD: 11287.96 requests per second, p50=1.703 msec
HSET: 10566.36 requests per second, p50=1.911 msec
SPOP: 9944.31 requests per second, p50=1.951 msec
ZADD: 9992.01 requests per second, p50=1.967 msec
ZPOPMIN: 10371.29 requests per second, p50=1.887 msec
LPUSH (needed to benchmark LRANGE): 10228.09 requests per second, p50=1.919 msec
LRANGE_100 (first 100 elements): 8338.89 requests per second, p50=2.263 msec
LRANGE_300 (first 300 elements): 5620.19 requests per second, p50=3.255 msec
LRANGE_500 (first 500 elements): 4011.55 requests per second, p50=4.623 msec
LRANGE_600 (first 600 elements): 3725.37 requests per second, p50=4.991 msec
MSET (10 keys): 8932.56 requests per second, p50=2.079 msec

在本地的测试结果

PING_INLINE: 35714.29 requests per second, p50=0.287 msec
PING_MBULK: 35285.81 requests per second, p50=0.295 msec
SET: 35599.86 requests per second, p50=0.311 msec
GET: 35958.29 requests per second, p50=0.303 msec
INCR: 35958.29 requests per second, p50=0.303 msec
LPUSH: 35001.75 requests per second, p50=0.327 msec
RPUSH: 34734.29 requests per second, p50=0.319 msec
LPOP: 35523.98 requests per second, p50=0.327 msec
RPOP: 34940.60 requests per second, p50=0.319 msec
SADD: 35498.76 requests per second, p50=0.311 msec
HSET: 34364.26 requests per second, p50=0.319 msec
SPOP: 35816.62 requests per second, p50=0.303 msec
ZADD: 34411.56 requests per second, p50=0.335 msec
ZPOPMIN: 35211.27 requests per second, p50=0.303 msec
LPUSH (needed to benchmark LRANGE): 34566.20 requests per second, p50=0.319 msec
LRANGE_100 (first 100 elements): 22784.23 requests per second, p50=0.455 msec
LRANGE_300 (first 300 elements): 9814.51 requests per second, p50=1.031 msec
LRANGE_500 (first 500 elements): 6954.59 requests per second, p50=1.447 msec
LRANGE_600 (first 600 elements): 5993.41 requests per second, p50=1.671 msec
MSET (10 keys): 35100.04 requests per second, p50=0.391 msec

Windows 本地Redis3.2.100的测试结果

PING_INLINE: 22296.54 requests per second
PING_BULK: 22872.83 requests per second
SET: 22967.39 requests per second
GET: 23380.88 requests per second
INCR: 22246.94 requests per second
LPUSH: 23375.41 requests per second
RPUSH: 22862.37 requests per second
LPOP: 23239.60 requests per second
RPOP: 22794.62 requests per second
SADD: 23299.16 requests per second
SPOP: 23062.73 requests per second
LPUSH (needed to benchmark LRANGE): 23272.05 requests per second
LRANGE_100 (first 100 elements): 12515.64 requests per second
LRANGE_300 (first 300 elements): 7000.84 requests per second
LRANGE_500 (first 450 elements): 5093.21 requests per second
LRANGE_600 (first 600 elements): 4213.72 requests per second
MSET (10 keys): 19845.21 requests per second

Windows 远程测试结果

PING_INLINE: 21422.45 requests per second, p50=0.863 msec
PING_MBULK: 24348.67 requests per second, p50=0.759 msec
SET: 25201.61 requests per second, p50=0.743 msec
GET: 25933.61 requests per second, p50=0.719 msec
INCR: 26034.89 requests per second, p50=0.719 msec
LPUSH: 26581.61 requests per second, p50=0.703 msec
RPUSH: 24888.00 requests per second, p50=0.751 msec
LPOP: 25542.79 requests per second, p50=0.735 msec
RPOP: 25406.50 requests per second, p50=0.735 msec
SADD: 25621.32 requests per second, p50=0.735 msec
HSET: 25733.40 requests per second, p50=0.727 msec
SPOP: 25879.92 requests per second, p50=0.727 msec
ZADD: 25859.84 requests per second, p50=0.727 msec

WorkStation的网络损耗的更多相关文章

  1. VMware Workstation Pro网络配置(WiFi配置等)

    常用技巧 连续按两下ctrl+alt,实现鼠标脱离 VMware Workstation Pro网络配置有几种模式: 桥接模式: 网络上的独立主机 占用路由器新IP资源 通过VMware Networ ...

  2. VMware Workstation中网络连接之桥接、NAT和Host-only

    在Windows XP系统中,安装好VMware Workstation虚拟机软件以后,我们可以查看一下"网络连接"窗口: 在窗口中多出了两块网卡: VMware Network ...

  3. [VMware WorkStation]虚拟机网络

    桥接模式下复制物理网络连接: 复制物理网卡连接状态,就是说把你指定的.本机的.真是网卡的状态信息复制给虚拟机的虚拟网卡,比如说你的本机真是网卡链接到了家用路由器的LAN口上,获得到了DHCP分配的地址 ...

  4. VMware Workstation的网络连接方式:NAT、桥接和Host Only

    安装完VMware Workstation后会自动生成两个网络连接:VMware Network Adapter VMnet8 和 VMware Network Adapter VMnet1(通常称为 ...

  5. VMware workstation 虚拟网络 三种上网区别

    以VMware workstation为例,其虚拟网络设备有3种: 第一种:vmnet0(桥接模式),无实体虚拟网卡,其实就是一个协议而已,会在对应网卡上加入VMware bridge protoco ...

  6. [转]VMware Workstation网络连接的三种模式

    经常要使用VMWare Workstation来在本地测试不同的操作系统,以前也搞不清楚网络连接三种模式,最近看了几篇文章才算明白.现总结如下: 1. VMware Workstation的虚拟网络组 ...

  7. WMware workstation中几种网络连接的说明 【转】

    博客来源:WMware workstation中几种网络连接的说明 VMware workstation中几种网络连接的说明 WMware workstation中网络连接包括,桥接模式.NAT模式. ...

  8. VMware workstation 网络选择 NAT模式 访问外网

    多年不用本地做测试  尽然被 nat 模式給卡着了  :动手的还是所以要记录一下: 1.根据自己需求创建 虚拟机 之后: 配置[网络适配器] -- 选择 nat 模式 ( 选择网卡 )   虚拟机   ...

  9. VMWare Workstation 配置docker多macvlan网络方法

    VMWare Workstation 配置docker多macvlan网络方法 答案就是.....换VirtualBox 噗... VMWare Workstation host-only网络,三台虚 ...

  10. 转-深入理解VMware虚拟网络

    原文出处:http://wangchunhai.blog.51cto.com/225186/381225 VMware Workstation是一款非常不错的虚拟机软件,许多爱好者用VMware Wo ...

随机推荐

  1. JavaImprove--Lesson06--正则表达式

    一.正则表达式的入门 正则表达式是一些特定支付组成的,代表一个规则,简化代码,以字符的形式体现规则 正则表达式,又称规则表达式,(Regular Expression,在代码中常简写为regex.re ...

  2. 文心一言 VS 讯飞星火 VS chatgpt (126)-- 算法导论11.1 1题

    一.用go语言,假设一动态集合 S用一个长度为 m 的直接寻址表T来表示.请给出一个查找 S 中最大元素的过程.你所给的过程在最坏情况下的运行时间是多少? 文心一言,代码正常运行: 在这个问题中,我们 ...

  3. 手把手教你使用ModelArts的自动学习识别毒蘑菇分类

    摘要:本文介绍了ModelArts如何通过自动学习进行毒蘑菇的识别. 想当年,白雪公主吃了毒蘑菇,换来了白马王子的一吻.如果白雪公主没有吃毒蘑菇,还会遇到白马王子吗?张小白觉得不见得--说不定她会遇到 ...

  4. 突破开源Redis的内存限制,存算分离的GaussDB到底有多能“装”?

    摘要:GaussDB(for Redis)(下文简称高斯Redis)是华为云数据库团队自主研发的兼容Redis协议的云原生数据库,该数据库采用计算存储分离架构,突破开源Redis的内存限制,可轻松扩展 ...

  5. 云数据库 GaussDB(for Influx) 解密第十一期:让智能电网中时序数据处理更高效

    摘要:GaussDB(for Influx)是一款基于计算存储分离架构,完全兼容 InfluxDB 生态的云原生时序数据库. 本文分享自华为云社区<云数据库 GaussDB(for Influx ...

  6. 中秋节,华为云AI送上超级大月亮制作教程,体验赢开发者键鼠套装

    摘要:一键"Run in ModelArts",无需考虑计算资源.环境的搭建,简单运行代码,即可拥有你的超级大月亮,打造专属于你的梦幻中秋月夜. 本文分享自华为云社区<中秋节 ...

  7. 带你读顶会论文丨基于溯源图的APT攻击检测

    摘要:本次分享主要是作者对APT攻击部分顶会论文阅读的阶段性总结,将从四个方面开展. 本文分享自华为云社区<[论文阅读] (10)基于溯源图的APT攻击检测安全顶会总结>,作者:eastm ...

  8. 前端资源共享方案对比-笔记:iframe/JS-SDK/微前端

    前端页面资源如何分享,常见的有iframe,其次是js-sdk.这两类的在地图类工具经常用.微前端是最佳比较火的方式.本篇是他们的对比分析. 下一篇讲 BK-VISION如何在让用户自由选择 ifra ...

  9. 信创就用国产的生态,Solon v2.6.4 发布

    Solon 是什么框架? Java 新的"生态级"应用开发框架.从零开始构建,有自己的标准规范与开放生态(历时六年,具备全球第二级别的生态规模). 相对于 Spring,有什么特点 ...

  10. Solon Aop 特色开发(4)Bean 扫描的三种方式

    Solon,更小.更快.更自由!本系列专门介绍Solon Aop方面的特色: <Solon Aop 特色开发(1)注入或手动获取配置> <Solon Aop 特色开发(2)注入或手动 ...