我们一般使用单位时间内服务器处理的请求数来描述其并发处理能力。称之为吞吐率（Throughput），单位是
“req/s”。吞吐率特指Web服务器单位时间内处理的请求数。
比如Apache 的 mod_status 模块提供的如下统计
另一种描述，吞吐率是，单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。它是衡量网络性能的重要指标。通常情况下，吞吐率“字节数/秒”来衡量。当然你也可以用“请求数/秒”和“页面数/秒”来衡量。其实不管一个请求还是一个页面，它的本质都是在网络上传输的数据，那么用来表述数据的单位就是字节数。
Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
是 Transactions Per
Second的缩写，也就是事务数/秒，这个完整的事务包括了用户请求服务器，服务器内部处理，服务器返回信息给用户三个过程。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息来估计得分。客户机使用加权协函数平均方法来计算客户机的得分，测试软件就是利用客户机的这些信息使用加权协函数平均方法来计算服务器端的整体TPS得分。
例子：一个高速路有10个入口，每个入口每秒钟只能进1辆车
1、请问1秒钟最多能进几辆车？
TPS=10
2、每辆车需要多长时间进行响应？
reponse time = 1
3、改成20辆车，每秒能进几辆？每辆车的响应时间是多长？
TPS = 10，reponse time = 1 (10个为一等份，分成两等份，平均tps
(10/1+10/2)/2=7.5 平均响应时间(2+1)/2=1.5
4、入口扩展到20个，每秒能进几辆？每辆车的响应时间是多长？
TPS = 20，reponse time = 1
5、看看，现在TPS变了，响应时间没变，TPS和响应时间有关系吗？
木有关系
6、如何理解？
TPS和响应时间在理想状态下都是额定值(联想运行一个压力测试场景来考虑)，把入口看成线程池，如果有20个入口，并发数只有10的时候，TPS就是10，而响应时间始终是1，说明并发数不够，需要增加并发数达到TPS的峰值。
7、同样是20个入口，如果并发数变成100的话，TPS和响应时间会怎么样呢？
并发数到100的时候，就会出现堵车，堵车了平均每个车过去的时间就长了，把100个车按照20一份分成5份，第5份的等待时间就是最长的，从等待开始到这个车进去，实际花费了5秒，那100辆车都过去的响应时间就是（5+4+3+2+1）/5=3，平均的TPS就是（20/1+20/2+20/3+20/4+20/5)/5=9.13（我怎么感觉应该是100/（5+4+3+2+1）=6.67
完成的事务总数/完成事务数的时间，使用该方法计算出来的tps会稍微小些,可以乘以1.5倍作为当前tps）
8、由此可知，TPS和响应时间宏观上是倒数关系，但是两者实际上木有直接的关系的，在上例中，系统只存在20个线程，100的并发就会造成线程的等待，引起平均响应时间从1秒增加到3秒，TPS从20下降到9，TPS和响应时间都是单独计算出来的，并不是互相算出来的！
VMware NSX is the company’s network virtualization and security
platform for the software-defined data center (SDDC).
传统的数据中心都是用物理网络来分隔不同的业务系统，这就需要管理员预先规划好数据中心的网络拓扑结构，划分好
VLAN，以确保各个业务系统之间是相互隔离的；并且在防火墙上配置上百条规则，针对每一个应用关闭不需要的网络端口，以降低黑客攻击的风险。这是一个费时费力的工作，一旦某个业务系统需要增加一些新的功能，或者不同的业务系统之间需要互相访问，就需要对数据中心内的网络做出相应的调整，这个过程不但费时，而且需要非常小心，避免任何一个错误的配置而导致网络中断。
SNAT
场景：云上的vm主机用户作为客户端访问外网服务器
vm(client)--->SNAT(将数据包中的内网源IP转换为外网IP)--->Internet(服务器）--->SNAT(将数据包内的目的IP转换为内网IP)--->vm(client)
DNAT
场景：云上的VM主机作为服务器端为外网提供服务
Internet(client用户)--->DNAT(将数据包中的目的公网IP转换为目的内网IP)--->VM(server)--->DNAT(将数据包中的源内网IP转换为外网IP)--->Internet(client用户)
首先需要解释一下三角传输的概念，该概念正常情况下适用于特定应用类型的服务器均衡项目中。为了明晰基本概念，我们先以正常环境下的数据流向示范。
常见的服务器部署方式中，最多的为旁路部署，因为该方式不需要用户改变网络拓扑结构，而旁路部署的特点就是，负载均衡设备的接口ip地址与服务器ip地址处于同一个网段（而根据vip地址是否也是属于同一个网段，分为了单臂旁路和双臂旁路）。为了简单起见，我们假设为单臂旁路方式。
以产品设计理念剖析企业建设故障自动化处理方案的思路
人工处理告警，一直是运维心中的痛。大年初一拜年、结婚、和老婆孩子外出过周末等美好时光，作为运维的你，好像一直心系IT系统，保持与笔记本的安全距离。
为什么这么多年过去了，还是这么苦逼，不是说运维行业转
AIOps了，我竟然还在手工处理告警，我该怎么办？
今天就和大家聊聊实现故障自愈要攻克的3个问题，以及献上开箱即用的方案。
自动化的要点是什么？把人的经验抽象、固化为程序处理，工业（第3次工业革命）或互联网都是如此。
举个例子，磁盘出现告警，运维首先想到的是登陆服务器清理磁盘。
产品经理工作中，画流程图是必经的一环。对于工具狂魔来说，和介于产品经理的通病，只要能画流程图的工具，总想体验一番。
我用过的流程图工具有Visio、MindManager、亿图图示专家（Edraw
Max）、PPT、Axure等。
首先，用Axure画流程图，对我来说，真废时间啊，布局还这么费力，反正我用不来。而Mindjet即使画流程图，我也用的是思维导图的形式，所以没有啥可比性。
其次，PPT画流程图，比如用它的SmartArt，做简单的流程演示，还是可行的。但无论从视觉美感、还是承载流程步骤的规模，PPT都没法和Edraw
Max相比。
所以，这篇文章重点要讲的流程图工具是Visio和Edraw
Max。但很遗憾，这不是一篇“流程图工具”竞品分析报表。我只是想说下我分别使用Visio和Edraw
Max后的看法。
