实时警报通知：微信告警通知的重要性解析
905
2022-12-28
包含双机房怎么做负载测试系统的词条
本站部分文章、图片属于网络上可搜索到的公开信息，均用于学习和交流用途，不能代表睿象云的观点、立场或意见。我们接受网民的监督，如发现任何违法内容或侵犯了您的权益，请第一时间联系小编邮箱jiasou666@gmail.com 处理。
本篇文章给大家谈谈双机房怎么做负载测试系统，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
今天给各位分享双机房怎么做负载测试系统的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
原有单机房的情况下，如果有网络问题或者极端情况造成服务瘫痪，双机房就能体现价值。
或者说A机房某服务挂掉了，但是B机房该服务还能work，需要A机房上游切量调用B机房下游服务
正常情况下:A_up调用A_down,B_up调用B_down
双机房情况下，支持自定义流量百分比，确认多少流量A_up打到B_down
服务发现中，实例可以加上机房标识符，比如上游叫做up.A,up.B,
下游叫做down.A,down.B
这样上游服务可以知道下游服务中，有down.A,down.B两组标识
上面说的每个标识，在服务发现（如zk，consul）中对应一个实例列表，会有下面最简单的结构
支持上游按照百分比指定调用下游量
比如
这样A.up调用下游down服务时，random一下，就能决定是调用A.down还是B.down
同样，如果决定了A.down,那么再在ip1:port1，ip2:port2，...中随机一下即可
这里可以拓展上下游的概念，
上游可以拓展到lb，lb决定多少量打到A机房api，多少量打到B机房api
下游也可以拓展到基础服务如redis，mysql，kafka，但是会涉及到主从同步问题
麻烦一点在于
1.双机房的注意事项
读写的分离，比如A机房为master，负责所有的写包括mysql，redis等，B机房能承担读的职责，如果A挂了，那么只能保证主要的读功能是work的
容量的配比，基本上要求是1双机房怎么做负载测试系统：1，不然A完全挂的时候，B扛不住。
正常的时候，A+B的流量才是1，但是A+B能够处理的总容量得是2
延迟双机房怎么做负载测试系统：跨机房调用毕竟有延迟，能同机房rpc尽量同机房rpc，同机房下游服务出问题了采取调用对端机房服务
2.api层A机房断了怎么办
lb层全部打到B机房去双机房怎么做负载测试系统？
怎么保证请求会到b机房的lb层双机房怎么做负载测试系统？
用类似域名下发的服务提供给客户端，客户端访问的时候都去访问B机房
（这下面涉及到网络模型等，暂时不是非常了解）
这几年API的作用不断演化，以前API还只是用来做内部系统之间的集成点，但现在API已成为一个公司的核心系统，一个构建于Web和移动端应用之上的核心系统。
当API仅只用来处理后台的任务（例如生成报告），那么性能差点也不是问题。但是如今API慢慢地发展成为连接服务与终端用户的核心纽带。这种关键性的角色变化表明了一个重要的观点：那就是API的性能真的很重要。
如果API数据源响应快，前端的应用程序的设计好点或差点影响不大，要是响应慢如蜗牛，前端的设计再出色也是然并卵。现在我们的客户端应用展示的数据源可能都是来自多个API响应内容的聚合，性能对这种微服务构架来说真的非常重要。
可以毫不夸张的说出色的性能就是你API提供的最好功能。我们知道向目标改进的唯一正确的方法就是找到问题的关键点，或者叫关键路径，并不断迭代测量和调整你的架构系统，直到系统达到预定的目标。对于API来说，测量和提高性能的过程就是负载与压力测试的过程。
本文将重点介绍如何对你的API进行负载压力测试。我们会以一个简单的、未测过的例子开始，然后再添加一个访问控制层，要确保一切都经过严格测试，做好处理真实流量的准备工作。OK，开始吧！
首先我们要明确要测试什么，可以是对你所有的API接口，或者是对单个API接口，或是对需要排除故障或改进的API接口的常规测试。
本文的其部分，我们将使用一个示例API。这是一个棋牌类游戏的Node.js API。它有三个API接口：
/question – 返回一个随机黑牌
/answer – 返回一个随机白牌
/pick – 返回一对随机的问题与答案
你测试用的负荷情况越和真实环境的越类似，你的负载测试就越有用。如果你不知道实际流量有多少或者你不知道负载在所有接口上是否都一致，那么就算你知道你的API可以保持400 请求/秒的吞吐量也没啥鸟用。
所以，你应该先从收集你API的使用数据开始。你可以直接从你的API服务日志或者从其他你在用的应用性能工具（例如New Relic）中获取数据。在对你的API进行第一次测试之前，你应该对以下问题做到心中有数：
（1）每秒请求数的平均吞吐量（Average throughput in requests per second）
（2）峰值吞吐量（您在某段时间内获得的最大流量是多少？）（Peak throughput）
（3）API各接口的吞吐量分布情况（有没有一些接口的流量远超其他接口？）
（4）用户的吞吐量分布情况（少数用户产生大多数的流量，或者是更均匀分布？）
另外还需要考虑的一个关键点是，在测试期间将要模拟的流量会是怎样的，主要考虑点是：
（1）重复负载生成（Repetitive load generation）
（2）模拟流量模式
（3）真实流量
通常我们最好以最简单的方法开始测试，然后逐步演化到更为接近真实环境的测试。我们可以先用重复负载生成来做为API接口的第一个测试，这样不仅可以验证我们的测试环境是否稳定，更重要的是可以让我们找到API能承受的最大吞吐量，这样我们就可以知道API可以达到的性能上限是多少。
找到你的API性能上限值后，你就可以开始考虑如何将你的生成的测试流量塑造得更接近真实环境。使用真实流量来测试是最理想的，但实际操作不太可行。要模拟真实流量比较难，也太花时间。所以我们有一个折中点的方法：先研究你的流量分析数据，并做一个简单的概率模拟。比如你有100个API接口（提示：原文endpoint在这里我译为接口，翻译成端点也可以，不过译成接口感觉更容易理解），你检查了上个月的使用情况，发现80%的流量来自20个接口，其中3个接口占用了50%的流量。那么你就可以创建一个遵循这种概率的请求列表，并提供给你的负载测试工具。这样做就相对快多了，并且它相对比较接近你真实负载，可以显示出你实际环境中可能遇到的问题。
最后，如果你拿到你要测试的API的真实访问日志，你就可以用它们来做最接近客观现实的测试。我们待会儿要讨论的大部分负载测试工具，都是接收一个请求列表作为输入文件。你可以用你的访问日志，稍微做一个格式调整就可以匹配每个测试工具所需的格式。搞定这个你就可以在测试环境中轻松重现你的生产流量。
好了，你清楚了你要测试什么鬼了，准备工作的最后一步就是配置好你的测试环境。你需要一个专用的测试环境。如果你不怕被你老板骂的话，或者比较任性，你也可以直接在你的生产环境中进行性能测试，不过出问题别说哥事先没跟你说清楚哈。
如果您已经设好一个预生产或沙箱环境，并且你的API也在上面运行了，那么你就万事俱备了。因为本文要用示例API，我们会在AWS的服务实例上设置我们的环境。
在我们的例子中，我们使用一个简单的API，不需要从磁盘读取或在内存中保存大型数据集。我们选择Linux C4.large 实例就够了。
注意：我们对比过其他相似处理资源数但内存更大的AWS实例，但实际测试中内存大部分没使用，所以我们选了C4.large
接下来，我们将一个配好的负载测试实例（服务器）运行起来，这只是一个运行模拟测试程序的服务器，它会通过从多个并发连接重复发送请求到我们的API服务器。你需要模拟的负载越高，机器的性能就要求越高。再次，这也是一个CPU密集型工作负载。这里我们选择具有4个虚拟核，16个 ECU的优化处理器的 c4.xlarge AWS服务器
我们选择在相同的可用区内部署所有实例（API服务器与测试服务器在同一个区/机房），这样可以将外部因素对我们测试结果的影响降到最小。
我们有一个沙箱环境来运行我们的API，同时也有另一台服务器准备开始负载测试。如果这是你第一次做性能测试，你一定会想知道什么是最好的方法。在本节中，我们将会分享我们如何选择工具，同时也会介绍一下目前市面上一些公认比较好的工具。
JMeter
在人们意识当中，首当翘楚的估计是 Apache JMeter ，这是一个开源的Java程序，他关键的特性就是提供一个强大而完善的创建测试计划的GUI。测试计划由测试组件组成，测试组件定义了测试的每一个部分，例如：
（1）用来注入负载测试的线程
（2）参数化测试中使用的HTTP请求
（3）可添加侦听器，象widget测试组件那样，可以以不同的方式显示测主式结果
优点：
（1）它是功能性负载测试的最好工具。你可以设定条件来为复杂的用户流建模，还可以创建断言来验证行为。
（2）轻松模拟复杂的http请求，比如请求前的登录验证或文件上传
（3）可扩展性强，有很多社区插件可以修改或扩展内置的行为
（4）开源并且免费
缺点：
（1）GUI学习曲线陡峭，一大堆的选项，在你运行第一个测试之前你得了解大量的概念。
（2）测试高负载时，操作步骤很麻烦。你需要先使用GUI工具来生成XML测试计划，然后在非GUI模式下导入测试计划运行测试，因为GUI会消耗掉本用于生成负载的大量资源。你还需要注意所有的侦听器（收集数据与展示测量的组件）哪些要被禁用或启用，因为它们也很耗资源。测试结束后后，你需要将原始结果数据导入GUI以才能查看结果。
（3）如果你的目标是测试一段时间内的持续吞吐量（例如在60秒内每秒请求1000次），那么很难找到正确的并发线程数量和计时器来求出一个比较稳定的数值。
JMeter只是我们在开始测试时用的工具，我们很快开始寻找其他替代方案。原因是，如果你的目标是在Web应用上压力测试复杂的用户流，那么JMeter可能是最好的工具，但如果你只是需要在一些HTTP API接口上进行性能测试，那用它就是杀鸡用牛刀了。
Wrk
Wrk 是一款和传统的 Apache Benchmark （最初用来做Apache服务器的测试工具）非常相似的工具。wrk和ab完全不同于JMeter：
（1）一切都是可以通过命令行工具配置和执行的。
（2）配置少但强大，只有基本生成HTTP负载的必要几项配置
（3）性能强悍
然而，和传统ab工具相比还是有几个优势的地方，主要是：
（1）多线程，所以能利用多核处理器的优势，更容易生成更高的负载
（2）利用Lua脚本很容易进行扩展默认的行为
不好的地方，主要是生成的默认报告在内容与格式上都受到限制（仅文本，无绘图）。当你的目标是找到你的API可以处理的最大负载量，那么wrk是你最佳选择工具。wrk用起来很快就可以上手。
Vegeta
Vegeta 是一款开源命令行工具，但它采用的方式不同于我们以前所见的工具。它专注于如何达到与维持每秒请求数速率。也就是说它侧重在测试支撑每秒X次请求时API会有怎样的服务行为，当你有实际的数据或对你将要达到的峰值流量有个估算时就非常有用，你可以用于验证你的API是否能满足你的需求。
SaaS 工具
正如你之前所看到的，运行一个简单的负载测试需要准备好配置环境。最近有些产品提供负载测试服务。我们试过两个， Loader.io 和 Blazemeter （话外：阿里也有性能测试工具 PTS ，老外估计没试过）。
注意：我们只试了这两个工具的免费版，所以得到的测试结果仅适用于免费版的限定。
Blazemeter
这个产品和我们前面提到的JMeter一样有同样的毛病：如果你只需要用在高负载测试，你需要在GUI界面上创建测试计划，然后在另一个运行非GUI模式的JMeter中导入这些计划。Blazemeter允许你上传JMeter的测试计划到他们的云端并运行，但可惜的是免费版只能设置50个并发用户。
Loader.io
它是一款 SendGrid 出品的简单而强大的云负载测试服务工具。它有你所需要的功能和漂亮的可视报告。 Loader.io 的免费版还是不错的，每秒最多可以有10000次请求的吞吐量，你基本上就可以用它来运行一个真实的负载测试。
我们推荐使用多个工具，以便可以多重检查我们的测试结果，不同的工具有不同的功能与方法，可以更多方面地反映测试结果。
我们先尝试找到我们的API可以承受的最大吞吐量。在这个吞吐量下，我们的API服务达到最大CPU利用率，同时不会返回任何错误或超时。这个吞吐量就可作为我们后面测试要用的每秒请求数。
同样，重要的是要注意到：CPU是限制因素之一，但你也还必须清楚地知道哪些资源会成为你API的性能瓶颈。
我们有必要在API服务器上安装一些工具，以便我们在测试过程中监控资源的利用率情况。我们使用 Keymetrics.io 和 PM2 模块。
我们的Node.js应用运行了一个非常简单的HTTP 服务。Node.js是单线程设计的，但为了利用c4.large AWS实例中提供的双核，我们使用PM2的集群功能来运行应用程序的两个工作进程。
由于我们的API是完全无状态的，所以很容易使用PM2的 核心集群模块（PM2在内部直接使用）。PM2提供的集群功能提供了不错的快捷命令来start/stop/reload应用程序，也可以监控进程。
我们先使用Loader.io对API进行测试。以下是持续30秒，每秒10,000次请求的测试结果，10000次请求是Loader.io免费版中允许的最大吞吐量。
在测试期间，我们观察到API服务器的CPU处理器在测试期间只有几次达到100％的容量。
这表示我们的API可能还可以处理更高的吞吐量。我们接下来通过运行wrk进行第二次测试证实了这一点。我们的目标就是要将我们的API服务器性能推到极限。
wrk -t 4 -c 1000 -d 60 --latency --timeout 3s http://api-server/questions
这里是我们对这个测试做了多次重复测试的结果：
Running 1m test @ http://api-server/question
4 threads and 1000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 62.23ms 30.85ms 1.35s 99.39%
Req/Sec 4.07k 357.61 5.27k 94.29%
Latency Distribution
50% 60.04ms
75% 63.85ms
90% 64.17ms
99% 75.86ms
972482 requests in 1.00m, 189.89MB read
Requests/sec: 16206.04
Transfer/sec: 3.16MB
结果表明，我们的预感被证实：它达到16,206请求/秒，同时保持合理的延迟，第99百分位只有75.86毫秒。 我们将这作为我们的基准最大吞吐量，因为这一次我们看到了API服务器的最大容量处理能力：
我们刚看到用一个简单的方式来找出你的API可承受的最大流量负载，同时在这过程中我们介绍并讨论了我们看到的一些工具。
请继续关注本文的第二部分，我们将介绍如何控制流量，不要让随随便便一个客户端就可以轻松搞跨您的API。 我们将展示如何通过在架构前端添加代理来确保我们的API的性能不受影响。
本文译自： How to load test tune performance on your API
前言：市面上现在天生支持绑定功能的网卡不多，而且多是出身名门的高档服务器网卡，身价不菲，设置过程也比较专业，使用和维护都不简便。难道我等平头百姓，攥着几十元的廉价8139的兄弟们就无缘领略双网卡绑定的快感了吗？非也，今天我就教大家一招，只需一款小小的软件，就可以用普通的8139之类的网卡体验一把双网卡绑定的愉悦，这个软件就叫做“NICExpress”，可能行家们已经捂着嘴乐了，呵呵，笔者的出发点是给菜鸟兄弟们排难解惑，穷办法自娱自乐，说得过火的地方，大家不要见笑，DIY的乐趣就在于此啊。
朋友或许会问了，为什么要用双网卡呢？用双网卡有什么好处？所谓双网卡，就是通过软件将双网卡绑定为一个IP地址，这个技术对于许多朋友来说并不陌生，许多高档服务器网卡（例如intel8255x系列、3COM服务器网卡等）都具有多网卡绑定功能，可以通过软硬件设置将两块或者多块网卡绑定在同一个IP地址上，使用起来就好象在使用一块网卡。
多网卡绑定的优点不少，首先，可以增大带宽，假如一个网卡的带宽是100M，理论上两块网卡就是200M，三块就是300M，当然实际上的效果是不会是这样简单的增加的，不过经实际测试使用多个网卡对于增加带宽，保持带宽的稳定性肯定是有裨益的，如果交换机等相关条件不错的话，这个效果还是很能令人满意；其次，可以形成网卡冗余阵列、分担负载，双网卡被绑定成“一块网卡”之后，同步一起工作，对服务器的访问流量被均衡分担到两块网卡上，这样每块网卡的负载压力就小多了，抗并发访问的能力提高，保证了服务器访问的稳定和畅快，当其中一块发生故障的时候，另一块立刻接管全部负载，过程是无缝的，服务不会中断，直到维修人员到来。
OK，现在就手把手的教大家如何用50元来打造出双网卡的效果！
先下载软件（点击这里下载），这是最新版本4.0，只有2.15M，软件的兼容性已经做得很好，支持win98/Me/2000/XP/2003。基本上支持目前市场上常见的各种网卡，百兆和千兆网卡都可以用来绑定，但是千万注意，最好用于绑定的网卡是完全相同的，至少也是基于同一芯片的，这样多块网卡才能合作得比较好。切记不要把10M网卡和100M网卡绑定在一起，那样根本起不到提升作用。
下载完软件，先不忙安装，咱们还是先准备好硬件。
第一部分：硬件安装
虽然，理论上讲绑定越多网卡在一起，最终效果提升就越明显，但是考虑到复杂程度，这里就以绑定双网卡为例进行说明，如果读者觉得好玩，兴致很高的话，按照下面方法愿意绑定多少就绑定多少个网卡，其实一般同一台服务器，绑定2－3块网卡也就够了，太多了，据说因为链路聚合的先天缺点，会过多占用服务器资源，反过来会影响服务器速度（关于这个我没实验，不过我觉得凡事都离不开物极必反的道理，适度最好）。
然后，抱出笔者的一台私有服务器，呵呵，虽然破旧一点，不过可是立功不小啊，上面现在运行着FTP、MAIL等服务，几百个朋友的EMAIL都是通过它来传递的啊。配置情况为intel810主板（集成显卡）＋256MSD内存＋10GIDE硬盘（系统盘）＋120GIDE硬盘（存放互联网垃圾）。系统软件是windows2000高级服务器版。
废话少说，开干，打开服务器机箱，把两块网卡拧在主板PCI插槽上，拧好了，看看还不错
拿出珍藏的10M－8口集线器，哈哈，别笑话，我手头只有这个，能说清楚方法就可以了，如果是读者自己DIY，请务必选一台好的交换机，至少要10/100M自适应的，这是网络通畅的关键，别象我把100M网卡连在10M集线器上，那速度怎么也好不了啊。做几条网线，把集线器、网卡连接起来，集线器连入上级交换机，因为是在家里实验，所以，我就把集线器的Uplink口连入家用路由器的任意一个网口里，路由器则连入我家ADSL“大猫”。
第二部分：设置调试
下面要进行设置及调试了，也就是要将这两块8139D廉价网卡，如同高档服务器网卡那样绑定在一起，使用同一个IP地址，同时同步工作。其过程并不复杂，估计20分钟足够了。
将刚刚下载的NIC Express软件的安装包NIC4.rar解压缩得到安装文件“NICExpressW2KEE.exe”，双击它启动安装程序，一路NEXT，软件提示输入unlock key（注册码），如果没有注册码，就只好点击Demo，选择试用，这样可以获得30天的免费试用期，在这30天里如果觉得不错，你可以想办法去弄一个注册码（怎么弄？找小编问，他可能有，哈哈）。
到下图所示界面，软件提示选择是否开启LOAD Balancing 功能？什么是LOAD Balancing 功能呢？LOAD Balancing的中文意思可以翻译为负载均衡，在这里就是网络负载均衡。也就是当多块网卡被绑定合一之后，当数据流量很大的时候，软件会自动调整，将数据流量负载均衡地分配到各个网卡上，以减轻单块网卡的压力，达到畅快的访问效果。我们绑定双网卡，其中目的之一就是为了实现负载均衡，我们自然要开启这个功能，所以，在这里一定要选择“Enabled”。当然，如果你在这里选择错了也没关系，今后也可以通过NIC Express软件管理界面开启。
继续一路NEXT，在Windows XP里安装时如果遇到提示“NIC Express Virtual Miniport”没有通过Windows测试，无法验证它同Windows XP的相容性，不要理会，选择“仍然继续”就行了。
到了下图所示界面，就到了真正绑定网卡的时候了：
大家看到这个界面一共分为上、中、下，三个窗口，上面的是空白，中间的写着8139-2，这个8139-2是我自己起的绑定之后的网卡组的名称，原来这里默认写的是New array，也可以不修改，你也可以根据自己喜好，写成别的名字。在最下面的窗口里列出了目前服务器上安装的两块网卡的名字。我们下一步就是要用鼠标选中下面的两块网卡名字，然后点击界面中间的Add键，把两块网卡加入上面的窗口里，这样两块网卡就这样被加入了网卡组里，初步绑定成一块“网卡”了，今后可以使用同一个IP地址了。
点击OK继续，NIC Express出现一个配置界面，选项很多，但是不必太操心，因为这些配置都不必修改，使用默认值就可以了，直接点击OK、点击Finish完成安装进程。至此软件安装基本结束，剩下就需要对软件和网卡进行一些必要的设置工作。
点击桌面“开始”菜单，选择执行菜单里的“NIC Express Enterprise Edition”选项，这是NIC Express软件自带的一个监控程序，首先点击“setting”选项，在这里可以设置网卡流量计量单位，可以按照Packets/Sec、Mbits/Sec、Kbits/Sec三种单位来计算，一般都是使用默认的Mbits/Sec来计算，也就是兆/每秒，其实在这里只需要修改一下“Graph Detail（图形显示）”即可，将默认的“By Protocol”改成“By Incoming/Outgoing”，别的不需要改。
如果你想分别观察绑定组中每块网卡的流量或者整个组的流量，只需在“Select Device”选项中选择一下设备即可。最后点击“Advanced”选项，设定网卡绑定的工作模式，在这里也可以点击“Load Balancing Disable”来关闭网卡负载均衡功能。使用NIC Express绑定的双网卡组默认工作于“NIC Express ELB”模式下，这是NIC Express所特有的一种工作模式，实际效果很好。我们都知道利用昂贵的Intel PROSET绑定的Intel 8255x的组合是运行在“802.3ad”工作模式下的，这一模式在NIC Express中也可以选择，但是多数使用者在实际使用后都认为“NIC Express ELB”模式的效果优于“802.3ad”模式，大家今后可以自己实践测试比较一下。如果你也使用默认的“NIC Express ELB”模式，那么“Advanced”选项里也就不用改什么，一切默认即可。至此NIC Express的设置结束。
第三部分：“虚拟网卡”设定
最后还要看看网卡的设置，用鼠标在桌面“网上邻居”上点击右键弹出“网络和拨号连接”窗口，可以看到原来的两个网卡连接图标已经变成了三个，多出来的一个图标就是“NIC Express Virtual Adapter”，这个就是绑定后的网卡组，这个网卡组的使用和使用单一网卡完全一样，相当于一个单一的“虚拟网卡”。
用鼠标在这个图标上点击右键选择属性，可以为这个“虚拟网卡”设定IP地址、子网掩码、网关等等，其实在安装“NIC Express”过程中，如果服务器原来的单一网卡已经设置了这些，那么“虚拟网卡”就会自动设定和原来的网卡一样。在这里选择“NIC Express Transport for Ethernet”还可以自由对网卡绑定组进行调整，例如，减少或者加入一块网卡，这个较之Intel PROSET要方便许多，Intel PROSET在增加或者减少绑定组里的网卡之前必须删除原来的绑定组然后重新创建。
好了，好了，至此一切都已经做好，我们的服务器已经成为一台地地道道的“双网卡冗余服务器”了，我们来运行一下，看看表现。
第四部分：测试双网卡绑定后的效果
检查一下线路，前面说过两块网卡已经用网线连入10M集线器（这就相当于机房机柜里的百兆交换机），集线器的Uplink口连入了家用路由器的任意一个网口，路由器通过ADSL大猫接入互联网（北京512K包月ADSL），这样服务器就已经和互联网连通了，按下Power键启动服务器，由于服务器里面已经安装了动态域名软件，服务器启动之后，很快与国际域名www.usacase.com连接到一起（具体过程请看不久前发表在太平洋网站的《绝对疯狂!1G容量的邮件服务器自己打造》），这时只要访问www.usacase.com域名，即可从世界各地访问到我的服务器了，我让上海的一个朋友用FTP软件登陆这台“双网卡冗余服务器”，下载一个50M的压缩文件包。嚯，只见服务器上的两块8139D网卡的指示灯同时闪烁起来，闪烁的频率完全同步，煞是好看！
再看那台古董级10M集线器，两个接上网卡的接口指示灯也是飞快同步闪烁，说明两块网卡在同步工作，同时分担访问的流量。上海的朋友说感觉速度不错，毕竟只是512K的ADSL，也仅能看看网卡同步闪烁的美丽效果了。
然后，我又在局域网里进行了传输实验，因为有那个10M集线器的瓶颈，所以效果不是很好，但是也能看出一些明显改善。从局域网另一台使用单个杂牌10M8029网卡的电脑上通过网上邻居访问已经用NIC Express绑定了双8139D网卡的服务器，传输200M文件，通过“NIC Express Enterprise Edition”中的曲线监控图观察到，双网卡绑定组的传输速率从8M/s起步，最高达到8.2M/s，两机之间平均传输速率比较稳定，偶尔有大幅度的波动，是软件正在调整两块网卡的负载均衡，只有零点几秒就恢复正常，基本稳定在7.5－8M/s左右，已经接近那个10M集线器的最大传输极限。之后，从服务器上删除一块网卡，再进行两机传输实验，发现传输最高速率已经骤然减少到5M/s，而且传输过程中速率上下波动很大，平均传输速率也就3M/s左右，可见前后差异还是很明显的。
本文目录一览：
双机房架构中服务负载均衡及思考
了解下双机房要考虑注意的事项，角度不一定完全原有单机房的情况下，如果有网络问题或者极端情况造成服务瘫痪，双机房就能体现价值。
或者说A机房某服务挂掉了，但是B机房该服务还能work，需要A机房上游切量调用B机房下游服务
正常情况下:A_up调用A_down,B_up调用B_down
双机房情况下，支持自定义流量百分比，确认多少流量A_up打到B_down
服务发现中，实例可以加上机房标识符，比如上游叫做up.A,up.B,
下游叫做down.A,down.B
这样上游服务可以知道下游服务中，有down.A,down.B两组标识
上面说的每个标识，在服务发现（如zk，consul）中对应一个实例列表，会有下面最简单的结构
支持上游按照百分比指定调用下游量
比如
这样A.up调用下游down服务时，random一下，就能决定是调用A.down还是B.down
同样，如果决定了A.down,那么再在ip1:port1，ip2:port2，...中随机一下即可
这里可以拓展上下游的概念，
上游可以拓展到lb，lb决定多少量打到A机房api，多少量打到B机房api
下游也可以拓展到基础服务如redis，mysql，kafka，但是会涉及到主从同步问题
麻烦一点在于
1.双机房的注意事项
读写的分离，比如A机房为master，负责所有的写包括mysql，redis等，B机房能承担读的职责，如果A挂了，那么只能保证主要的读功能是work的
容量的配比，基本上要求是1双机房怎么做负载测试系统：1，不然A完全挂的时候，B扛不住。
正常的时候，A+B的流量才是1，但是A+B能够处理的总容量得是2
延迟双机房怎么做负载测试系统：跨机房调用毕竟有延迟，能同机房rpc尽量同机房rpc，同机房下游服务出问题了采取调用对端机房服务
2.api层A机房断了怎么办
lb层全部打到B机房去双机房怎么做负载测试系统？
怎么保证请求会到b机房的lb层双机房怎么做负载测试系统？
用类似域名下发的服务提供给客户端，客户端访问的时候都去访问B机房
（这下面涉及到网络模型等，暂时不是非常了解）
如何对API进行负载测试与调优（一）
本文由Donny译自 3scale.com 的 《How to load test tune performance on your API》这几年API的作用不断演化，以前API还只是用来做内部系统之间的集成点，但现在API已成为一个公司的核心系统，一个构建于Web和移动端应用之上的核心系统。
当API仅只用来处理后台的任务（例如生成报告），那么性能差点也不是问题。但是如今API慢慢地发展成为连接服务与终端用户的核心纽带。这种关键性的角色变化表明了一个重要的观点：那就是API的性能真的很重要。
如果API数据源响应快，前端的应用程序的设计好点或差点影响不大，要是响应慢如蜗牛，前端的设计再出色也是然并卵。现在我们的客户端应用展示的数据源可能都是来自多个API响应内容的聚合，性能对这种微服务构架来说真的非常重要。
可以毫不夸张的说出色的性能就是你API提供的最好功能。我们知道向目标改进的唯一正确的方法就是找到问题的关键点，或者叫关键路径，并不断迭代测量和调整你的架构系统，直到系统达到预定的目标。对于API来说，测量和提高性能的过程就是负载与压力测试的过程。
本文将重点介绍如何对你的API进行负载压力测试。我们会以一个简单的、未测过的例子开始，然后再添加一个访问控制层，要确保一切都经过严格测试，做好处理真实流量的准备工作。OK，开始吧！
首先我们要明确要测试什么，可以是对你所有的API接口，或者是对单个API接口，或是对需要排除故障或改进的API接口的常规测试。
本文的其部分，我们将使用一个示例API。这是一个棋牌类游戏的Node.js API。它有三个API接口：
/question – 返回一个随机黑牌
/answer – 返回一个随机白牌
/pick – 返回一对随机的问题与答案
你测试用的负荷情况越和真实环境的越类似，你的负载测试就越有用。如果你不知道实际流量有多少或者你不知道负载在所有接口上是否都一致，那么就算你知道你的API可以保持400 请求/秒的吞吐量也没啥鸟用。
所以，你应该先从收集你API的使用数据开始。你可以直接从你的API服务日志或者从其他你在用的应用性能工具（例如New Relic）中获取数据。在对你的API进行第一次测试之前，你应该对以下问题做到心中有数：
（1）每秒请求数的平均吞吐量（Average throughput in requests per second）
（2）峰值吞吐量（您在某段时间内获得的最大流量是多少？）（Peak throughput）
（3）API各接口的吞吐量分布情况（有没有一些接口的流量远超其他接口？）
（4）用户的吞吐量分布情况（少数用户产生大多数的流量，或者是更均匀分布？）
另外还需要考虑的一个关键点是，在测试期间将要模拟的流量会是怎样的，主要考虑点是：
（1）重复负载生成（Repetitive load generation）
（2）模拟流量模式
（3）真实流量
通常我们最好以最简单的方法开始测试，然后逐步演化到更为接近真实环境的测试。我们可以先用重复负载生成来做为API接口的第一个测试，这样不仅可以验证我们的测试环境是否稳定，更重要的是可以让我们找到API能承受的最大吞吐量，这样我们就可以知道API可以达到的性能上限是多少。
找到你的API性能上限值后，你就可以开始考虑如何将你的生成的测试流量塑造得更接近真实环境。使用真实流量来测试是最理想的，但实际操作不太可行。要模拟真实流量比较难，也太花时间。所以我们有一个折中点的方法：先研究你的流量分析数据，并做一个简单的概率模拟。比如你有100个API接口（提示：原文endpoint在这里我译为接口，翻译成端点也可以，不过译成接口感觉更容易理解），你检查了上个月的使用情况，发现80%的流量来自20个接口，其中3个接口占用了50%的流量。那么你就可以创建一个遵循这种概率的请求列表，并提供给你的负载测试工具。这样做就相对快多了，并且它相对比较接近你真实负载，可以显示出你实际环境中可能遇到的问题。
最后，如果你拿到你要测试的API的真实访问日志，你就可以用它们来做最接近客观现实的测试。我们待会儿要讨论的大部分负载测试工具，都是接收一个请求列表作为输入文件。你可以用你的访问日志，稍微做一个格式调整就可以匹配每个测试工具所需的格式。搞定这个你就可以在测试环境中轻松重现你的生产流量。
好了，你清楚了你要测试什么鬼了，准备工作的最后一步就是配置好你的测试环境。你需要一个专用的测试环境。如果你不怕被你老板骂的话，或者比较任性，你也可以直接在你的生产环境中进行性能测试，不过出问题别说哥事先没跟你说清楚哈。
如果您已经设好一个预生产或沙箱环境，并且你的API也在上面运行了，那么你就万事俱备了。因为本文要用示例API，我们会在AWS的服务实例上设置我们的环境。
在我们的例子中，我们使用一个简单的API，不需要从磁盘读取或在内存中保存大型数据集。我们选择Linux C4.large 实例就够了。
注意：我们对比过其他相似处理资源数但内存更大的AWS实例，但实际测试中内存大部分没使用，所以我们选了C4.large
接下来，我们将一个配好的负载测试实例（服务器）运行起来，这只是一个运行模拟测试程序的服务器，它会通过从多个并发连接重复发送请求到我们的API服务器。你需要模拟的负载越高，机器的性能就要求越高。再次，这也是一个CPU密集型工作负载。这里我们选择具有4个虚拟核，16个 ECU的优化处理器的 c4.xlarge AWS服务器
我们选择在相同的可用区内部署所有实例（API服务器与测试服务器在同一个区/机房），这样可以将外部因素对我们测试结果的影响降到最小。
我们有一个沙箱环境来运行我们的API，同时也有另一台服务器准备开始负载测试。如果这是你第一次做性能测试，你一定会想知道什么是最好的方法。在本节中，我们将会分享我们如何选择工具，同时也会介绍一下目前市面上一些公认比较好的工具。
JMeter
在人们意识当中，首当翘楚的估计是 Apache JMeter ，这是一个开源的Java程序，他关键的特性就是提供一个强大而完善的创建测试计划的GUI。测试计划由测试组件组成，测试组件定义了测试的每一个部分，例如：
（1）用来注入负载测试的线程
（2）参数化测试中使用的HTTP请求
（3）可添加侦听器，象widget测试组件那样，可以以不同的方式显示测主式结果
优点：
（1）它是功能性负载测试的最好工具。你可以设定条件来为复杂的用户流建模，还可以创建断言来验证行为。
（2）轻松模拟复杂的http请求，比如请求前的登录验证或文件上传
（3）可扩展性强，有很多社区插件可以修改或扩展内置的行为
（4）开源并且免费
缺点：
（1）GUI学习曲线陡峭，一大堆的选项，在你运行第一个测试之前你得了解大量的概念。
（2）测试高负载时，操作步骤很麻烦。你需要先使用GUI工具来生成XML测试计划，然后在非GUI模式下导入测试计划运行测试，因为GUI会消耗掉本用于生成负载的大量资源。你还需要注意所有的侦听器（收集数据与展示测量的组件）哪些要被禁用或启用，因为它们也很耗资源。测试结束后后，你需要将原始结果数据导入GUI以才能查看结果。
（3）如果你的目标是测试一段时间内的持续吞吐量（例如在60秒内每秒请求1000次），那么很难找到正确的并发线程数量和计时器来求出一个比较稳定的数值。
JMeter只是我们在开始测试时用的工具，我们很快开始寻找其他替代方案。原因是，如果你的目标是在Web应用上压力测试复杂的用户流，那么JMeter可能是最好的工具，但如果你只是需要在一些HTTP API接口上进行性能测试，那用它就是杀鸡用牛刀了。
Wrk
Wrk 是一款和传统的 Apache Benchmark （最初用来做Apache服务器的测试工具）非常相似的工具。wrk和ab完全不同于JMeter：
（1）一切都是可以通过命令行工具配置和执行的。
（2）配置少但强大，只有基本生成HTTP负载的必要几项配置
（3）性能强悍
然而，和传统ab工具相比还是有几个优势的地方，主要是：
（1）多线程，所以能利用多核处理器的优势，更容易生成更高的负载
（2）利用Lua脚本很容易进行扩展默认的行为
不好的地方，主要是生成的默认报告在内容与格式上都受到限制（仅文本，无绘图）。当你的目标是找到你的API可以处理的最大负载量，那么wrk是你最佳选择工具。wrk用起来很快就可以上手。
Vegeta
Vegeta 是一款开源命令行工具，但它采用的方式不同于我们以前所见的工具。它专注于如何达到与维持每秒请求数速率。也就是说它侧重在测试支撑每秒X次请求时API会有怎样的服务行为，当你有实际的数据或对你将要达到的峰值流量有个估算时就非常有用，你可以用于验证你的API是否能满足你的需求。
SaaS 工具
正如你之前所看到的，运行一个简单的负载测试需要准备好配置环境。最近有些产品提供负载测试服务。我们试过两个， Loader.io 和 Blazemeter （话外：阿里也有性能测试工具 PTS ，老外估计没试过）。
注意：我们只试了这两个工具的免费版，所以得到的测试结果仅适用于免费版的限定。
Blazemeter
这个产品和我们前面提到的JMeter一样有同样的毛病：如果你只需要用在高负载测试，你需要在GUI界面上创建测试计划，然后在另一个运行非GUI模式的JMeter中导入这些计划。Blazemeter允许你上传JMeter的测试计划到他们的云端并运行，但可惜的是免费版只能设置50个并发用户。
Loader.io
它是一款 SendGrid 出品的简单而强大的云负载测试服务工具。它有你所需要的功能和漂亮的可视报告。 Loader.io 的免费版还是不错的，每秒最多可以有10000次请求的吞吐量，你基本上就可以用它来运行一个真实的负载测试。
我们推荐使用多个工具，以便可以多重检查我们的测试结果，不同的工具有不同的功能与方法，可以更多方面地反映测试结果。
我们先尝试找到我们的API可以承受的最大吞吐量。在这个吞吐量下，我们的API服务达到最大CPU利用率，同时不会返回任何错误或超时。这个吞吐量就可作为我们后面测试要用的每秒请求数。
同样，重要的是要注意到：CPU是限制因素之一，但你也还必须清楚地知道哪些资源会成为你API的性能瓶颈。
我们有必要在API服务器上安装一些工具，以便我们在测试过程中监控资源的利用率情况。我们使用 Keymetrics.io 和 PM2 模块。
我们的Node.js应用运行了一个非常简单的HTTP 服务。Node.js是单线程设计的，但为了利用c4.large AWS实例中提供的双核，我们使用PM2的集群功能来运行应用程序的两个工作进程。
由于我们的API是完全无状态的，所以很容易使用PM2的 核心集群模块（PM2在内部直接使用）。PM2提供的集群功能提供了不错的快捷命令来start/stop/reload应用程序，也可以监控进程。
我们先使用Loader.io对API进行测试。以下是持续30秒，每秒10,000次请求的测试结果，10000次请求是Loader.io免费版中允许的最大吞吐量。
在测试期间，我们观察到API服务器的CPU处理器在测试期间只有几次达到100％的容量。
这表示我们的API可能还可以处理更高的吞吐量。我们接下来通过运行wrk进行第二次测试证实了这一点。我们的目标就是要将我们的API服务器性能推到极限。
wrk -t 4 -c 1000 -d 60 --latency --timeout 3s http://api-server/questions
这里是我们对这个测试做了多次重复测试的结果：
Running 1m test @ http://api-server/question
4 threads and 1000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 62.23ms 30.85ms 1.35s 99.39%
Req/Sec 4.07k 357.61 5.27k 94.29%
Latency Distribution
50% 60.04ms
75% 63.85ms
90% 64.17ms
99% 75.86ms
972482 requests in 1.00m, 189.89MB read
Requests/sec: 16206.04
Transfer/sec: 3.16MB
结果表明，我们的预感被证实：它达到16,206请求/秒，同时保持合理的延迟，第99百分位只有75.86毫秒。 我们将这作为我们的基准最大吞吐量，因为这一次我们看到了API服务器的最大容量处理能力：
我们刚看到用一个简单的方式来找出你的API可承受的最大流量负载，同时在这过程中我们介绍并讨论了我们看到的一些工具。
请继续关注本文的第二部分，我们将介绍如何控制流量，不要让随随便便一个客户端就可以轻松搞跨您的API。 我们将展示如何通过在架构前端添加代理来确保我们的API的性能不受影响。
本文译自： How to load test tune performance on your API
网络机房供配电系统怎么测试呀
网络机房一般配备有UPS 和交流屏和整流开关电源系统或配备有-48v直流电池、逆变器等设备双机房怎么做负载测试系统，设备安装调测运行稳定后均可投入使用双机房怎么做负载测试系统，输出如果是交流双机房怎么做负载测试系统的话可以用笔记本、电脑等设备进行带载测试双机房怎么做负载测试系统，如果输出是直流设备的话可以用直流负载箱进行带载测试。双网卡服务器的网络负载平衡如何设置？
双网卡负载均衡服务器前言：市面上现在天生支持绑定功能的网卡不多，而且多是出身名门的高档服务器网卡，身价不菲，设置过程也比较专业，使用和维护都不简便。难道我等平头百姓，攥着几十元的廉价8139的兄弟们就无缘领略双网卡绑定的快感了吗？非也，今天我就教大家一招，只需一款小小的软件，就可以用普通的8139之类的网卡体验一把双网卡绑定的愉悦，这个软件就叫做“NICExpress”，可能行家们已经捂着嘴乐了，呵呵，笔者的出发点是给菜鸟兄弟们排难解惑，穷办法自娱自乐，说得过火的地方，大家不要见笑，DIY的乐趣就在于此啊。
朋友或许会问了，为什么要用双网卡呢？用双网卡有什么好处？所谓双网卡，就是通过软件将双网卡绑定为一个IP地址，这个技术对于许多朋友来说并不陌生，许多高档服务器网卡（例如intel8255x系列、3COM服务器网卡等）都具有多网卡绑定功能，可以通过软硬件设置将两块或者多块网卡绑定在同一个IP地址上，使用起来就好象在使用一块网卡。
多网卡绑定的优点不少，首先，可以增大带宽，假如一个网卡的带宽是100M，理论上两块网卡就是200M，三块就是300M，当然实际上的效果是不会是这样简单的增加的，不过经实际测试使用多个网卡对于增加带宽，保持带宽的稳定性肯定是有裨益的，如果交换机等相关条件不错的话，这个效果还是很能令人满意；其次，可以形成网卡冗余阵列、分担负载，双网卡被绑定成“一块网卡”之后，同步一起工作，对服务器的访问流量被均衡分担到两块网卡上，这样每块网卡的负载压力就小多了，抗并发访问的能力提高，保证了服务器访问的稳定和畅快，当其中一块发生故障的时候，另一块立刻接管全部负载，过程是无缝的，服务不会中断，直到维修人员到来。
OK，现在就手把手的教大家如何用50元来打造出双网卡的效果！
先下载软件（点击这里下载），这是最新版本4.0，只有2.15M，软件的兼容性已经做得很好，支持win98/Me/2000/XP/2003。基本上支持目前市场上常见的各种网卡，百兆和千兆网卡都可以用来绑定，但是千万注意，最好用于绑定的网卡是完全相同的，至少也是基于同一芯片的，这样多块网卡才能合作得比较好。切记不要把10M网卡和100M网卡绑定在一起，那样根本起不到提升作用。
下载完软件，先不忙安装，咱们还是先准备好硬件。
第一部分：硬件安装
虽然，理论上讲绑定越多网卡在一起，最终效果提升就越明显，但是考虑到复杂程度，这里就以绑定双网卡为例进行说明，如果读者觉得好玩，兴致很高的话，按照下面方法愿意绑定多少就绑定多少个网卡，其实一般同一台服务器，绑定2－3块网卡也就够了，太多了，据说因为链路聚合的先天缺点，会过多占用服务器资源，反过来会影响服务器速度（关于这个我没实验，不过我觉得凡事都离不开物极必反的道理，适度最好）。
然后，抱出笔者的一台私有服务器，呵呵，虽然破旧一点，不过可是立功不小啊，上面现在运行着FTP、MAIL等服务，几百个朋友的EMAIL都是通过它来传递的啊。配置情况为intel810主板（集成显卡）＋256MSD内存＋10GIDE硬盘（系统盘）＋120GIDE硬盘（存放互联网垃圾）。系统软件是windows2000高级服务器版。
废话少说，开干，打开服务器机箱，把两块网卡拧在主板PCI插槽上，拧好了，看看还不错
拿出珍藏的10M－8口集线器，哈哈，别笑话，我手头只有这个，能说清楚方法就可以了，如果是读者自己DIY，请务必选一台好的交换机，至少要10/100M自适应的，这是网络通畅的关键，别象我把100M网卡连在10M集线器上，那速度怎么也好不了啊。做几条网线，把集线器、网卡连接起来，集线器连入上级交换机，因为是在家里实验，所以，我就把集线器的Uplink口连入家用路由器的任意一个网口里，路由器则连入我家ADSL“大猫”。
第二部分：设置调试
下面要进行设置及调试了，也就是要将这两块8139D廉价网卡，如同高档服务器网卡那样绑定在一起，使用同一个IP地址，同时同步工作。其过程并不复杂，估计20分钟足够了。
将刚刚下载的NIC Express软件的安装包NIC4.rar解压缩得到安装文件“NICExpressW2KEE.exe”，双击它启动安装程序，一路NEXT，软件提示输入unlock key（注册码），如果没有注册码，就只好点击Demo，选择试用，这样可以获得30天的免费试用期，在这30天里如果觉得不错，你可以想办法去弄一个注册码（怎么弄？找小编问，他可能有，哈哈）。
到下图所示界面，软件提示选择是否开启LOAD Balancing 功能？什么是LOAD Balancing 功能呢？LOAD Balancing的中文意思可以翻译为负载均衡，在这里就是网络负载均衡。也就是当多块网卡被绑定合一之后，当数据流量很大的时候，软件会自动调整，将数据流量负载均衡地分配到各个网卡上，以减轻单块网卡的压力，达到畅快的访问效果。我们绑定双网卡，其中目的之一就是为了实现负载均衡，我们自然要开启这个功能，所以，在这里一定要选择“Enabled”。当然，如果你在这里选择错了也没关系，今后也可以通过NIC Express软件管理界面开启。
继续一路NEXT，在Windows XP里安装时如果遇到提示“NIC Express Virtual Miniport”没有通过Windows测试，无法验证它同Windows XP的相容性，不要理会，选择“仍然继续”就行了。
到了下图所示界面，就到了真正绑定网卡的时候了：
大家看到这个界面一共分为上、中、下，三个窗口，上面的是空白，中间的写着8139-2，这个8139-2是我自己起的绑定之后的网卡组的名称，原来这里默认写的是New array，也可以不修改，你也可以根据自己喜好，写成别的名字。在最下面的窗口里列出了目前服务器上安装的两块网卡的名字。我们下一步就是要用鼠标选中下面的两块网卡名字，然后点击界面中间的Add键，把两块网卡加入上面的窗口里，这样两块网卡就这样被加入了网卡组里，初步绑定成一块“网卡”了，今后可以使用同一个IP地址了。
点击OK继续，NIC Express出现一个配置界面，选项很多，但是不必太操心，因为这些配置都不必修改，使用默认值就可以了，直接点击OK、点击Finish完成安装进程。至此软件安装基本结束，剩下就需要对软件和网卡进行一些必要的设置工作。
点击桌面“开始”菜单，选择执行菜单里的“NIC Express Enterprise Edition”选项，这是NIC Express软件自带的一个监控程序，首先点击“setting”选项，在这里可以设置网卡流量计量单位，可以按照Packets/Sec、Mbits/Sec、Kbits/Sec三种单位来计算，一般都是使用默认的Mbits/Sec来计算，也就是兆/每秒，其实在这里只需要修改一下“Graph Detail（图形显示）”即可，将默认的“By Protocol”改成“By Incoming/Outgoing”，别的不需要改。
如果你想分别观察绑定组中每块网卡的流量或者整个组的流量，只需在“Select Device”选项中选择一下设备即可。最后点击“Advanced”选项，设定网卡绑定的工作模式，在这里也可以点击“Load Balancing Disable”来关闭网卡负载均衡功能。使用NIC Express绑定的双网卡组默认工作于“NIC Express ELB”模式下，这是NIC Express所特有的一种工作模式，实际效果很好。我们都知道利用昂贵的Intel PROSET绑定的Intel 8255x的组合是运行在“802.3ad”工作模式下的，这一模式在NIC Express中也可以选择，但是多数使用者在实际使用后都认为“NIC Express ELB”模式的效果优于“802.3ad”模式，大家今后可以自己实践测试比较一下。如果你也使用默认的“NIC Express ELB”模式，那么“Advanced”选项里也就不用改什么，一切默认即可。至此NIC Express的设置结束。
第三部分：“虚拟网卡”设定
最后还要看看网卡的设置，用鼠标在桌面“网上邻居”上点击右键弹出“网络和拨号连接”窗口，可以看到原来的两个网卡连接图标已经变成了三个，多出来的一个图标就是“NIC Express Virtual Adapter”，这个就是绑定后的网卡组，这个网卡组的使用和使用单一网卡完全一样，相当于一个单一的“虚拟网卡”。
用鼠标在这个图标上点击右键选择属性，可以为这个“虚拟网卡”设定IP地址、子网掩码、网关等等，其实在安装“NIC Express”过程中，如果服务器原来的单一网卡已经设置了这些，那么“虚拟网卡”就会自动设定和原来的网卡一样。在这里选择“NIC Express Transport for Ethernet”还可以自由对网卡绑定组进行调整，例如，减少或者加入一块网卡，这个较之Intel PROSET要方便许多，Intel PROSET在增加或者减少绑定组里的网卡之前必须删除原来的绑定组然后重新创建。
好了，好了，至此一切都已经做好，我们的服务器已经成为一台地地道道的“双网卡冗余服务器”了，我们来运行一下，看看表现。
第四部分：测试双网卡绑定后的效果
检查一下线路，前面说过两块网卡已经用网线连入10M集线器（这就相当于机房机柜里的百兆交换机），集线器的Uplink口连入了家用路由器的任意一个网口，路由器通过ADSL大猫接入互联网（北京512K包月ADSL），这样服务器就已经和互联网连通了，按下Power键启动服务器，由于服务器里面已经安装了动态域名软件，服务器启动之后，很快与国际域名www.usacase.com连接到一起（具体过程请看不久前发表在太平洋网站的《绝对疯狂!1G容量的邮件服务器自己打造》），这时只要访问www.usacase.com域名，即可从世界各地访问到我的服务器了，我让上海的一个朋友用FTP软件登陆这台“双网卡冗余服务器”，下载一个50M的压缩文件包。嚯，只见服务器上的两块8139D网卡的指示灯同时闪烁起来，闪烁的频率完全同步，煞是好看！
再看那台古董级10M集线器，两个接上网卡的接口指示灯也是飞快同步闪烁，说明两块网卡在同步工作，同时分担访问的流量。上海的朋友说感觉速度不错，毕竟只是512K的ADSL，也仅能看看网卡同步闪烁的美丽效果了。
然后，我又在局域网里进行了传输实验，因为有那个10M集线器的瓶颈，所以效果不是很好，但是也能看出一些明显改善。从局域网另一台使用单个杂牌10M8029网卡的电脑上通过网上邻居访问已经用NIC Express绑定了双8139D网卡的服务器，传输200M文件，通过“NIC Express Enterprise Edition”中的曲线监控图观察到，双网卡绑定组的传输速率从8M/s起步，最高达到8.2M/s，两机之间平均传输速率比较稳定，偶尔有大幅度的波动，是软件正在调整两块网卡的负载均衡，只有零点几秒就恢复正常，基本稳定在7.5－8M/s左右，已经接近那个10M集线器的最大传输极限。之后，从服务器上删除一块网卡，再进行两机传输实验，发现传输最高速率已经骤然减少到5M/s，而且传输过程中速率上下波动很大，平均传输速率也就3M/s左右，可见前后差异还是很明显的。
如何对IDC机房网络带宽进行测试
资料来源于，找机房公众号
【干货】非“程序猿”如何正确评估一个机房的带宽质量？
对于机房带宽质量的评估，目前还没有一个准确的方法和标准。对于机房采购人员来说，一般可以从以下三个方面进行评估。
一、网络稳定性
检测机房的网络延迟、丢包率可以使用ping、smokeping、mtr三种工具来进行测试。
Ping测试法（windows）：
1、 在windows系统下打开“运行”。快捷键：win+R
2、 在运行窗口内输入“cmd”点击确定
3、 在打开的命令框内输入“ping（空格）–t（空格）www.zhaojifang.com”然后敲击回车。
输入“ping –t www.zhaojifang.com”命令就是表示向“找机房网站”连续发送数据包。其中网络延迟，就是表示你目前访问“找机房网站”所需时间。（1/ms为1毫秒）
如果在Ping的过程中出现请求超时，则表示该次请求未得到相应，就是所谓的丢包。
Ping的过程，是电脑与目标服务器互相通信的过程，一旦出现丢包情况，则表示该次通信不成功，如果丢包率过高，将会影响用户的正常访问。
如上图，在整个测试阶段，丢包次数为1次，丢包率为0%，平均访问速度为19ms（数值越低访问质量越高）
Ping测试法（Linux）：
Linux系统Ping的命令语法：
ping(选项)(参数)
其中选项为Ping的前置规则，比如Ping几次、时间间隔等
-d：使用Socket的SO_DEBUG功能；
-c<完成次数：设置完成要求回应的次数；
-f：极限检测；
-i<间隔秒数：指定收发信息的间隔时间；
-I<网络界面：使用指定的网络界面送出数据包；
-l<前置载入：设置在送出要求信息之前，先行发出的数据包；
-n：只输出数值；
-p<范本样式：设置填满数据包的范本样式；
-q：不显示指令执行过程，开头和结尾的相关信息除外；
-r：忽略普通的Routing Table，直接将数据包送到远端主机上；
-R：记录路由过程；
-s<数据包大小：设置数据包的大小；
-t<存活数值：设置存活数值TTL的大小；
-v：详细显示指令的执行过程。
例如：ping -c 2 www.zhaojifang.com，则表示ping两次后自动退出
smokeping测试法：
smokeping是一款监视网络性能的工具，功能包括常规的ping、用echoping监控www 服务器性能、监视dns 查询性能、监视ssh 性能等。特点是画的图非常漂亮，网络丢包和延迟用颜色和阴影来表示。
相对Ping的办法，smokeping需要进行相应的环境配置和安装，对小白来说就相对比较复杂的多。（具体的配置安装请查询网上教程）
mtr测试法：
mtr是一款Linux环境下判断网络连通性工具，它可以结合ping nslookup tracert 来判断网络的相关特性。
mtr命令把ping命令和tracepath命令合成了一个。mtr会持续发包，并显示每一跳ping所用的时间。也会显示过程中的任何问题，在下面的示例中，可以看到第3行的丢包率为13.7%。
二、网络的传输速度
网络的传输速度也就是网络的上传速度和下载的速度，网络上传和下载速度的快慢决定了数据传输速度的快慢。
测试机房的上传和下载速度一是通过第三方网站进行测试，二是使用相关的测试工具。
1、 第三方网站测试
17CE：https://ce.com/
卡卡网：http://www.webkaka.com/
找机房：http://www.zhaojifang.com/
找机房的机房评测功能，可以针对机房的Ping、丢包率、上传、下载、TCP等提供综合测试报告。
2、 测试工具
webbench：Webbench是一个在linux下使用的非常简单的网站压测工具。它使用fork()模拟多个客户端同时访问设定的URL，测试网站在压力下工作的性能，最多可以模拟3万个并发连接去测试网站的负载能力。
Iperf：Iperf 是一个网络性能测试工具。Iperf可以测试最大TCP和UDP带宽性能，具有多种参数和UDP特性，可以根据需要调整，可以报告带宽、延迟抖动和数据包丢失。
三、网络接入位置
机房网络接入路由设备与骨干网之间的位置，其中的跳数越少越好。可以通过路由跟踪来评估网络接入位置。测试工具mtr/tracert等
也就是说，直连骨干网的数据中心要比非直连骨干网的数据中心网络质量要好，其网络覆盖区域就越大。
Tracert（跟踪路由）：是路由跟踪实用程序，用于确定 IP 数据包访问目标所采取的路径。Tracert 命令用 IP 生存时间 (TTL) 字段和 ICMP 错误消息来确定从一个主机到网络上其他主机的路由。
在上图中，数据包必须通过两个路由器（10.0.0.1 和 192.168.0.1）才能到达主机172.16.0.99。主机的默认网关是 10.0.0.1，192.168.0.0 网络上的路由器的 IP 地址是 192.168.0.1。
mtr是一款Linux环境下判断网络连通性工具，它可以结合ping nslookup tracert 来判断网络的相关特性。（上面有介绍，不再重复）
相关文章
发表评论
暂时没有评论，来抢沙发吧~