什么是RPS？

RPS -- Reverse Proxy Server

分享数码照片 高效传送大文件 在自己的电脑上建立网站 RPS统统为你做到

我们的承诺是，不断改善，永远免费！

--------------------------------------------------------------------------------

NEWS more

2004-4-14 服务器系统重装！已恢复工作。

近日即将推出能够自动连接服务器的RPS_client版本。当RPS_client与服务器的连接中断时，可自动恢复连接，再也无需手动重新启动RPS_client。

2004-4-13 修复了客户端窗口缩小到系统托盘后无法被弹出的bug。

--------------------------------------------------------------------------------

什么是Reverse Proxy Server？

Reverse Proxy Server可以让互联网上的用户访问，在内网你自己的电脑上搭建的web server或者是用HttpFileServer共享出来的文件。这样，我们就可以通过网络给远方的客户传送文件、与朋友分享你的照片、你喜欢的音乐甚至电影，而对方所需要做的只是打开浏览器，访问你的主页而已。

使用RPS发送文件或者发布网站的用户，可以使用任何互联网接入方式，拨号、ADSL、公司局域网以及小区宽带均可适用。

--------------------------------------------------------------------------------

安装、使用方法:

下载HttpFileServer，解开到某个目录，鼠标双击执行hfs.exe，将你要共享的文件用鼠标拖入HttpFileServer的窗口中；

下载RPS client，解开压缩文件到某个目录，鼠标双击执行其中的RPS_Web.exe，在“用户名”一栏填入你的ID，比如“john”,这个用户名可以取你喜欢的任何名字，无需注册，但必须是英文字母。然后，点击“连接”按钮，程序会化几秒钟时间连接服务器，连接成功后会隐藏到屏幕右下角的系统托盘中。

这时候，地球上的任何人，自要他(她)能访问到internet，就可以通过这个地址：

http://smdnb.vicp.net:8080/你的ID/

来访问你共享的文件或者你的主页。其中“你的ID”要替换成你自己取的名字，比如对john来说，访问他的地址就是：

http://smdnb.vicp.net:8080/john/

--------------------------------------------------------------------------------

点击这里下载 RPS client for Windows

点击这里下载 RPS client for Linux

点击这里下载 HttpFileServer (for Windows only)

--------------------------------------------------------------------------------

有任何问题或者建议请与作者联系：vbforlinux@etang.com

作者将会非常感谢你提出的宝贵建议！谢谢！

关于 QPS、TPS、PV、UV、GMV、IP、RPS 这些词语，看起来好像挺专业。但实际上，我认为是这是每个程序员必懂的知识点了，你可以搞不懂它们怎么计算的，但是你最少要了解它们分别代表什么意思。

2019年12月09日 - 初稿

阅读原文 - https://wsgzao.github.io/post/qps/

扩展阅读

Queries Per Second，每秒查询数。每秒能够响应的查询次数。

QPS 是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。每秒的响应请求数，也即是最大吞吐能力。

Transactions Per Second 的缩写，每秒处理的事务数目。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息作出的评估分。

TPS 的过程包括：客户端请求服务端、服务端内部处理、服务端返回客户端。

例如，访问一个 Index 页面会请求服务器 3 次，包括一次 html，一次 css，一次 js，那么访问这一个页面就会产生一个 “T”，产生三个 “Q”。

Page View 即页面浏览量，通常是衡量一个网络新闻频道或网站甚至一条网络新闻的主要指标。户每一次对网站中的每个页面访问均被记录 1 次。用户对同一页面的多次刷新，访问量累计。

根据这个特性，刷网站的 PV 就很好刷了。

与 PV 相关的还有 RV ，即重复访问者数量 Repeat Visitors。

访问数（Unique Visitor）指独立访客访问数，统计 1 天内访问某站点的用户数 (以 cookie 为依据)，一台电脑终端为一个访客。

（Internet Protocol）独立 IP 数，是指 1 天内多少个独立的 IP 浏览了页面，即统计不同的 IP 浏览用户数量。同一 IP 不管访问了几个页面，独立 IP 数均为 1；不同的 IP 浏览页面，计数会加 1。IP 是基于用户广域网 IP 地址来区分不同的访问者的，所以，多个用户（多个局域网 IP）在同一个路由器（同一个广域网 IP）内上网，可能被记录为一个独立 IP 访问者。如果用户不断更换 IP，则有可能被多次统计。

是 Gross Merchandise Volume 的简称。只要是订单，不管消费者是否付款、卖家是否发货、是否退货，都可放进 GMV 。

代表吞吐率，即 Requests Per Second 的缩写。吞吐率是服务器并发处理能力的量化描述，单位是 reqs/s，指的是某个并发用户数下单位时间内处理的请求数。

某个并发用户数下单位时间内能处理的最大的请求数，称之为最大吞吐率。

为了解决LVS ksoftirqd CPU使用率100%导致网卡软中断丢包，我和同事们一起搜索了大量的资料去分析问题，特别是感谢美团技术团队的分享帮助我们快速梳理优化思路，最后明确了如何重构RPS和RFS网卡多队列的优化脚本。个人认为这是一个大家可能普遍会遇到的问题，文章内的分析思路和解决方案未必是最优解，也欢迎各位分享自己的解决方法。

2019年07月03日 - 初稿

阅读原文 - https://wsgzao.github.io/post/rps/

扩展阅读

Redis 高负载下的中断优化 - https://tech.meituan.com/2018/03/16/redis-high-concurrency-optimization.html

我们遇到的问题属于计划外的incident，现象是某产品用户在线率突然降低，LVS Master同时收到CPU High Load告警，检查发现该节点出现网卡大量断开重连和丢包情况，应急切换到LVS Slave也出现上述问题，在排除掉流量异常和外部攻击后选择切换DNS到背后的Nginx Real Servers后服务逐步恢复。

复盘核心原因在于系统初始化时rps优化脚本没有成功执行，这个脚本起初是因为早期DBA团队遇到过CPU负载较高导致网卡异常，这个优化脚本也一直传承至今，却已经没有人知道为什么添加。现在大多数服务器没有执行成功而被大家一直所忽视显然也是post check没有做到位。在早期大家都停留在Bash Shell运维的阶段，没有专职的团队来管理确实容易失控，好在现在可以基于Ansible来做初始化和检查，运维的压力也减轻了一部分。

通过Google搜索相关知识的过程中，我们也发现在不少人都会遇到这样类似的问题。比如这篇文章提到 lvs/irq

lvs 的性能问题，软中断耗尽 CPU 单核后到达处理极限

和华为的工程师们在交换经验的时候对方分享了一个关于RSS和RPS关系图，之后的内容还会引用美团技术团队的分析

我们遇到的情况是缺少可用服务器资源选择把用户外部请求流量和Codis Cache Cluster内部流量临时混在了同一个LVS上，虽然看上去CPU和traffic的整体压力都不算高，但是CPU的处理压力可能恰好集中在了和外网Bond1网卡相同的Core上最后引起了ksoftirqd软中断，而内网Bond0网卡就没有监控到任何丢包。虽然我们也有正常开启 irqbalance ，但不清楚是不是因为受到 cpupower performance 和 NUMA 的影响最后也没能阻止事故的发生，最终的优化方案主要是手动开启RPS和RFS，大致步骤如下：

This document describes a set of complementary techniques in the Linux

networking stack to increase parallelism and improve performance for

multi-processor systems.

The following technologies are described:

https://www.kernel.org/doc/Documentation/networking/scaling.txt

RECEIVE PACKET STEERING (RPS)

Receive Packet Steering (RPS) is similar to RSS in that it is used to direct packets to specific CPUs for processing. However, RPS is implemented at the software level, and helps to prevent the hardware queue of a single network interface card from becoming a bottleneck in network traffic.

RPS has several advantages over hardware-based RSS:

RPS is configured per network device and receive queue, in the /sys/class/net/*device*/queues/*rx-queue*/rps_cpus file, where device is the name of the network device (such as eth0 ) and rx-queue is the name of the appropriate receive queue (such as rx-0 ).

The default value of the rps_cpus file is zero. This disables RPS, so the CPU that handles the network interrupt also processes the packet.

To enable RPS, configure the appropriate rps_cpus file with the CPUs that should process packets from the specified network device and receive queue.

The rps_cpus files use comma-delimited CPU bitmaps. Therefore, to allow a CPU to handle interrupts for the receive queue on an interface, set the value of their positions in the bitmap to 1. For example, to handle interrupts with CPUs 0, 1, 2, and 3, set the value of rps_cpus to 00001111 (1+2+4+8), or f (the hexadecimal value for 15).

For network devices with single transmit queues, best performance can be achieved by configuring RPS to use CPUs in the same memory domain. On non-NUMA systems, this means that all available CPUs can be used. If the network interrupt rate is extremely high, excluding the CPU that handles network interrupts may also improve performance.

For network devices with multiple queues, there is typically no benefit to configuring both RPS and RSS, as RSS is configured to map a CPU to each receive queue by default. However, RPS may still be beneficial if there are fewer hardware queues than CPUs, and RPS is configured to use CPUs in the same memory domain.

RECEIVE FLOW STEERING (RFS)

Receive Flow Steering (RFS) extends RPS behavior to increase the CPU cache hit rate and thereby reduce network latency. Where RPS forwards packets based solely on queue length, RFS uses the RPS backend to calculate the most appropriate CPU, then forwards packets based on the location of the application consuming the packet. This increases CPU cache efficiency.

RFS is disabled by default. To enable RFS, you must edit two files:

/proc/sys/net/core/rps_sock_flow_entries

Set the value of this file to the maximum expected number of concurrently active connections. We recommend a value of 32768 for moderate server loads. All values entered are rounded up to the nearest power of 2 in practice.

/sys/class/net/*device*/queues/*rx-queue*/rps_flow_cnt

Replace device with the name of the network device you wish to configure (for example, eth0 ), and rx-queue with the receive queue you wish to configure (for example, rx-0 ).

Set the value of this file to the value of rps_sock_flow_entries divided by N , where N is the number of receive queues on a device. For example, if rps_flow_entries is set to 32768 and there are 16 configured receive queues, rps_flow_cnt should be set to 2048 . For single-queue devices, the value of rps_flow_cnt is the same as the value of rps_sock_flow_entries .

Data received from a single sender is not sent to more than one CPU. If the amount of data received from a single sender is greater than a single CPU can handle, configure a larger frame size to reduce the number of interrupts and therefore the amount of processing work for the CPU. Alternatively, consider NIC offload options or faster CPUs.

Consider using numactl or taskset in conjunction with RFS to pin applications to specific cores, sockets, or NUMA nodes. This can help prevent packets from being processed out of order.

接收数据包是一个复杂的过程，涉及很多底层的技术细节，但大致需要以下几个步骤：

NIC 在接收到数据包之后，首先需要将数据同步到内核中，这中间的桥梁是 rx ring buffer 。它是由 NIC 和驱动程序共享的一片区域，事实上， rx ring buffer 存储的并不是实际的 packet 数据，而是一个描述符，这个描述符指向了它真正的存储地址，具体流程如下：

当驱动处理速度跟不上网卡收包速度时，驱动来不及分配缓冲区，NIC 接收到的数据包无法及时写到 sk_buffer ，就会产生堆积，当 NIC 内部缓冲区写满后，就会丢弃部分数据，引起丢包。这部分丢包为 rx_fifo_errors ，在 /proc/net/dev 中体现为 fifo 字段增长，在 ifconfig 中体现为 overruns 指标增长。

这个时候，数据包已经被转移到了 sk_buffer 中。前文提到，这是驱动程序在内存中分配的一片缓冲区，并且是通过 DMA 写入的，这种方式不依赖 CPU 直接将数据写到了内存中，意味着对内核来说，其实并不知道已经有新数据到了内存中。那么如何让内核知道有新数据进来了呢？答案就是中断，通过中断告诉内核有新数据进来了，并需要进行后续处理。

提到中断，就涉及到硬中断和软中断，首先需要简单了解一下它们的区别：

当 NIC 把数据包通过 DMA 复制到内核缓冲区 sk_buffer 后，NIC 立即发起一个硬件中断。CPU 接收后，首先进入上半部分，网卡中断对应的中断处理程序是网卡驱动程序的一部分，之后由它发起软中断，进入下半部分，开始消费 sk_buffer 中的数据，交给内核协议栈处理。

通过中断，能够快速及时地响应网卡数据请求，但如果数据量大，那么会产生大量中断请求，CPU 大部分时间都忙于处理中断，效率很低。为了解决这个问题，现在的内核及驱动都采用一种叫 NAPI（new API）的方式进行数据处理，其原理可以简单理解为 中断 + 轮询，在数据量大时，一次中断后通过轮询接收一定数量包再返回，避免产生多次中断。

由于接收来自外围硬件 (相对于 CPU 和内存) 的异步信号或者来自软件的同步信号，而进行相应的硬件、软件处理；发出这样的信号称为进行中断请求 (interrupt request, IRQ)

1.top 按下数字键 1

2.mpstat -P ALL 2

mpstat使用介绍和输出参数详解 - https://wsgzao.github.io/post/mpstat/

---