之前文章《Linux服务器性能评估与优化(一)》太长，阅读不方便，因此拆分成系列博文：
传统TCP/IP技术处理数据包需通过操作系统和其他软件层，导致数据在系统内存、处理器缓存和网络控制器缓存间频繁复制，增加了服务器CPU和内存的负担，特别是在网络带宽、处理器速度与内存带宽不匹配时，网络延迟会进一步加剧。RDMA技术通过将数据处理从CPU旁路并卸载到硬件上来实现低时延和高带宽特性。
Ping是Linux系统常用的网络命令，它通常用来测试与目标主机的连通性，我们经常会说“ping一下某机器，看是不是开着。它是通过发送ICMP ECHO_REQUEST数据包到网络主机，并显示响应情况，这样我们就可以根据它输出的信息来确定目标主机是否可访问（但这不是绝对的）。
『不管项目大小，一旦上线，或多或少都会遇到性能问题』性能问题就像是魔咒一般藏绕着我们。 性能优化应该什么时候开始 有些性能问题是随着时间的积累慢慢产生的，比如系统一开始数据量很小的时候，没有什么问题，等到数据积累到一定程度，问题就暴露出来了；有些问题是由于访问量的过大造成的，比如系统平时没问题，一到搞活动时就挂；也有些问题是遗留系统经过太多人去维护修改，导致各种坏代码味道性能问题仿佛到处存在。性能问题就如同一颗定时炸弹，只要数据量访问量一上来，或者各个团队在开发迭代中没有注重性能的意识，早晚会炸。既然迟早会
随着IoT的兴起，越来越多的嵌入式设备内置了Wi-Fi模块，具备了网络接入能力。 在开发过程中，难免会遇到各种各样的网络问题，而抓包无疑是分析网络问题最直接、最有效的手段。因为通过抓包可以明确问题是处于发送端还是接收端，迅速缩小排查范围。 然而，许多嵌入式设备上运行的可能不是Linux系统，而是一些实时操作系统(RTOS），甚至根本就没有操作系统。而和设备通信的对端也不一定能运行tcpdump或者wireshark等抓包工具。这使得常见的点对点抓包手段失效。
" 如果你怀念 SDN 领域丰富的网络能力却在云原生领域苦苦追寻而不得，那么 Kube-OVN 将是你的最佳选择。本系列我们将逐个介绍Kube-OVN高级功能的工作原理及使用路径，帮你尽快征服容器网络难题！"
1. Requests per second（RPS）：Nginx 每秒处理的请求数（也就是 QPS）。
工具：htop, net-tools, ping, iperf, UnixBench 等
默认情况下，每个客户端都是在一个请求完成之后才发送下一个请求 （benchmark 会模拟 50 个客户端除非使用 -c 指定特别的数量）， 这意味着服务器几乎是按顺序读取每个客户端的命令。Also RTT is payed as well.
这篇文章是对 OSDI20 的 Best Paper hXDP: Efficient Software Packet Processing on FPGA NICs 的阅读笔记，感兴趣的同学可以点击阅读原文查看论文的 paper，slide 和 video。
默认情况下，每个客户端都是在一个请求完成之后才发送下一个请求 （benchmark 会模拟 50 个客户端除非使用 -c 指定特别的数量）， 这意味着服务器几乎是按顺序读取每个客户端的命令。Also RTT is payed as well.
RED方法：监控服务的请求数（Rate）、错误数（Errors）、响应时间（Duration）。Weave Cloud在监控微服务性能时提出的思路。
PS：对于架构来说rocketMq的性能至关重要，只要用到消息队列的都是比较核心的应用，所以很多东西需要处理。
业务价值->承载高并发->性能优化。 一切的前提是业务价值需要。如果没有足够价值，那可读性才是第一，性能在需要的地方是no.1，但不需要的地方可能就是倒数第一。当下技术框架出来的软件差不到哪去，没有这种及时响应诉求的地方，削峰下慢慢跑就是了。（但工作中常需要在缺少价值的地方着手性能优化。异步，并发编程，逻辑缓存，算法真的会加剧系统的复杂度，得不偿失。如果没那个价值，简单才是王道）。
前几天跟某互联网主题旅游网架构师聊起性能调优的话题，那个时候正好遇到一些线上调优的一些困惑，希望一起探讨一下。
原文链接：https://cilium.io/blog/2021/05/11/cni-benchmark
很多架构师都是从软件开发成长起来的，大家在软件领域都有很深的造诣，大部分人对硬件接触的很少。而成为架构师后需要频繁的跟人 、硬件 、软件 、网络打交道，本篇文章就给大家带来服务器硬件方面的相关知识，主要包括服务器、CPU、内存、磁盘、网卡。
上一篇 "大型网站架构概述，我们必须要理解的这五个架构要素" ，我们主要一起理解了大型网站架构设计中高性能，高可用，可伸缩，可扩展和安全性这五大要素，知道了怎么通过这些架构要素来衡量我们整体系统架构设计的优劣。
本篇文章是为不知道技术的HR老师们如何问问题的时候方便搜索，不会面试直接看这篇文章就够了。
在Linux系统中，绑定双网卡可以实现网络负载均衡和故障容错。当一张网卡出现故障时，系统可以自动切换到另一张网卡，保证网络的稳定性和可靠性。本文将介绍如何在Linux系统中进行双网卡绑定。
使用 GPU 进行网络数据包内联处理是一种数据包分析技术，可用于许多不同的应用领域：信号处理、网络安全、信息收集、输入重建等。
https://blog.csdn.net/weixin_33725722/article/details/89131555
1、CPU，如果存在大量的计算，他们会长时间不间断的占用CPU资源，导致其他资源无法争夺到CPU而响应缓慢，从而带来系统性能问题，例如频繁的FullGC，以及多线程造成的上下文频繁的切换，都会导致CPU繁忙，一般情况下CPU使用率<75%比较合适。 2、内存，Java内存一般是通过jvm内存进行分配的，主要是用jvm中堆内存来存储Java创建的对象。内存的读写速度非常快，但是内存空间又是有限的，当内存空间被占满，对象无法回收时，就会导致内存溢出或内存泄漏。 3、磁盘I/O，磁盘的存储空间要比内存存储空间大很多，但是磁盘的读写速度比内存慢，虽然现在引入SSD固态硬盘，但是还是无法跟内存速度相比。 4、网络，带宽的大小，会对传输数据有很大影响，当并发量增加时，网络很容易就会成为瓶颈。 5、异常，Java程序，抛出异常，要对异常进行捕获，这个过程要消耗性能，如果在高并发的情况下，持续进行异常处理，系统的性能会受影响。 6、数据库，数据库的操作一般涉及磁盘I/O的读写，大量的数据库读写操作，会导致磁盘I/O性能瓶颈，进而导致数据库操作延迟。 7、当在并发编程的时候，经常会用多线程操作同一个资源，这个时候为了保证数据的原子性，就要使用到锁，锁的使用会带来上下文切换，从而带来性能开销，在JDK1.6之后新增了偏向锁、自旋锁、轻量级锁、锁粗化、锁消除。
最近一位小伙伴去某滴面试，在第二面的时候遇到了这个问题：说”请你简单说一下，Kafka为什么这么快？“，然后，这位小伙伴努力在大脑里检索了很久，没有回答上来。
sar 可以用来查看系统的网络收发情况，不仅可以观察网络收发的吞吐量（BPS，每秒收发的字节数），还可以观察网络收发的 PPS
你想建设一个能承受500万PV/每天的网站吗？ 500万PV是什么概念？服务器每秒要处理多少个请求才能应对？如果计算呢？ PV是什么： PV是page view的简写。PV是指页面的访问次数，每打开或刷新一次页面，就算做一个pv。 计算模型： 每台服务器每秒处理请求的数量=((80%总PV量)/(24小时60分60秒40%)) / 服务器数量 。 其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中（很适合互联网的应用，白天请求多，晚上请求少）。 简单计算的结果： ((80%500万)/(24小时60分60秒40%))/1 = 115.7个请求/秒 ((80%100万)/(24小时60分60秒40%))/1 = 23.1个请求/秒 初步结论： 现在我们在做压力测试时，就有了标准，如果你的服务器一秒能处理115.7个请求，就可以承受500万PV/每天。如果你的服务器一秒能处理23.1个请求，就可以承受100万PV/每天。 留足余量： 以上请求数量是均匀的分布在白天的9.6个小时中，但实际情况并不会这么均匀的分布，会有高峰有低谷。为了应对高峰时段，应该留一些余地，最少也要x2倍，x3倍也不为过。 115.7个请求/秒 *2倍=231.4个请求/秒 115.7个请求/秒 *3倍=347.1个请求/秒 23.1个请求/秒 *2倍=46.2个请求/秒 23.1个请求/秒 3倍=69.3个请求/秒 最终结论： 如果你的服务器一秒能处理231.4--347.1个请求/秒，就可以应对平均500万PV/每天。 如果你的服务器一秒能处理46.2--69.3个请求，就可以应对平均100万PV/每天。 说明： 这里说明每秒N个请求，就是QPS。因为我关心的是应用程序处理业务的能力。 实际经验：
将 Kubernetes 的 CNI 从其他组件切换为 Cilium, 已经可以有效地提升网络的性能. 但是通过对 Cilium 不同模式的切换/功能的启用, 可以进一步提升 Cilium 的网络性能. 具体调优项包括不限于:
你想建设一个能承受500万PV/每天的网站吗？ 500万PV是什么概念？服务器每秒要处理多少个请求才能应对？如果计算呢？ PV是什么： PV是page view的简写。PV是指页面的访问次数，每打开或刷新一次页面，就算做一个pv。 计算模型： 每台服务器每秒处理请求的数量=((80%总PV量)/(24小时60分60秒40%)) / 服务器数量 。 其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中（很适合互联网的应用，白天请求多，晚上请求少）。 简单计算的结果： ((80%500万)/(24小时60分60秒40%))/1 = 115.7个请求/秒 ((80%100万)/(24小时60分60秒40%))/1 = 23.1个请求/秒 初步结论： 现在我们在做压力测试时，就有了标准，如果你的服务器一秒能处理115.7个请求，就可以承受500万PV/每天。如果你的服务器一秒能处理23.1个请求，就可以承受100万PV/每天。 留足余量： 以上请求数量是均匀的分布在白天的9.6个小时中，但实际情况并不会这么均匀的分布，会有高峰有低谷。为了应对高峰时段，应该留一些余地，最少也要x2倍，x3倍也不为过。 115.7个请求/秒 *2倍=231.4个请求/秒 115.7个请求/秒 *3倍=347.1个请求/秒 23.1个请求/秒 *2倍=46.2个请求/秒 23.1个请求/秒 3倍=69.3个请求/秒 最终结论： 如果你的服务器一秒能处理231.4--347.1个请求/秒，就可以应对平均500万PV/每天。 如果你的服务器一秒能处理46.2--69.3个请求，就可以应对平均100万PV/每天。 说明： 这里说明每秒N个请求，就是QPS。因为我关心的是应用程序处理业务的能力。 实际经验： 1、根据实际经验，采用两台常规配置的机架式服务器，配置是很常见的配置，例如一个4核CPU+4G内存+服务器SAS硬盘。 2、硬盘的性能很重要，由其是数据库服务器。一般的服务器都配1.5万转的SAS硬盘，高级一点的可以配SSD固态硬盘，性能会更好。最最最最重要的指标是“随机读写性能”而不是“顺序读写性能”。（本例还是配置最常见的1.5万转的SAS硬盘吧） 3、一台服务器跑Tomcat运行j2ee程序,一台服务器跑MySql数据库,程序写的中等水平(这个真的不好量化)，是论坛类型的应用(总有回帖,不太容易做缓存,也无法静态化)。 4、以上软硬件情况下，是可以承受100万PV/每天的。(已留有余量应对突然的访问高峰) 注意机房的网络带宽： 有人说以上条件我都满足了，但实际性能还是达不到目标。这时请注意你对外的网络的带宽，在国内服务器便宜但带宽很贵，很可能你在机房是与大家共享一条100M的光纤，实际每个人可分到2M左右带宽。再好一点5M,再好一点双线机房10M独享，这已经很贵了（北京价格）。 一天总流量：每个页面20k字节100万个页面/1024=19531M字节=19G字节， 19531M/9.6小时=2034M/小时=578K字节/s 如果请求是均匀分布的，需要5M（640K字节）带宽（5Mb=640KB 注意大小写，b是位，B是字节，差了8倍），但所有请求不可能是均匀分布的，当有高峰时5M带宽一定不够，X2倍就是10M带宽。10M带宽基本可以满足要求。 以上是假设每个页面20k字节，基本不包含图片，要是包含图片就更大了，10M带宽也不能满足要求了。你自已计算吧。 （全文完） 附：性能测试基本概念
吞吐量是指对网络、设备、端口、虚电路或其他设施，单位时间内成功地传送数据的数量（以比特、字节、分组等测量）。
一款线上产品如果没有经过性能测试，那它就好比是一颗定时炸弹，你不知道它什么时候会出现问题，你也不清楚它能承受的极限在哪儿。
有的应用需要大量计算，他们会长时间、不间断占用CPU资源，导致其他资源无法争夺CPU而响应缓慢，从而带来系统性能问题。例如：代码递归导致的无限循环，正则表达式引起的回溯问题，JVM频繁的FULL GC，以及多线程编程导致的大量上下文切换等，这些都是导致CPU资源繁忙的因素。
答案：系统在一定的压力情况下，查看cpu，内存，磁盘，网络带宽，TPS、响应时间、并发用户数、等各项指标，通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求，就是在特定的运行条件下验证系统的能力状况。
▐ 2016年，戴尔易安信开始在其主流服务器上部署25Gb以太网，经过四年的发展和培育，25Gb以太网已经被用户广泛接受，并与万兆以太网平分秋色。
导语 随着版本升级，关系型数据库和缓存数据库整体性能比之前都有大幅度的提升，衡量数据库性能的三个重要指标是：数据库吞吐量(QPS)、延迟时长(Latency)和稳定性，以下从这三个方面对几种数据库进行
服务器台数= 2 * （生产者峰值生产速率 * 副本 / 100） + 1，即 2 * （20m/s * 2 / 100） + 1= 3 台。建议 3 台服务器。
性能测试是通过测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试。验证软件系统是否能够达到用户提出的性能指标，发现系统中存在的性能瓶颈并加以优化。
Hi，大家好，今天依然是金三银四面试系列，如果你想了解之前的面试相关文章可以在文末点击👉「阅读原文」查看更多或者点击以下👇「蓝色字」查看最近文章。 金三银四跳槽季，自动化面试题预热一波 金三银四求职季，接口自动化面试题助攻一波 金三银四季招聘季，APP测试面试题温新一遍 以下分享性能测试相关面试题，欢迎在文末留言补充评论✍️。 一 解释常用的性能指标名称与具体含义 性能测试是通过测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试。验证软件系统是否能够达到用户提出的性能指标，发现系统中
关于性能优化这是一个比较大的话题，在《由12306.cn谈谈网站性能技术》中我从业务和设计上说过一些可用的技术以及那些技术的优缺点，今天，想从一些技术细节上谈谈性能优化，主要是一些代码级别的技术和方法。本文的东西是我的一些经验和知识，并不一定全对，希望大家指正和补充。 在开始这篇文章之前，大家可以移步去看一下酷壳以前发表的《代码优化概要》，这篇文章基本上告诉你——要进行优化，先得找到性能瓶颈！ 但是在讲如何定位系统性能瓶劲之前，请让我讲一下系统性能的定义和测试，因为没有这两件事，后面的定位和优化无从谈起。
本节主要从监控告警的角度，深入了解腾讯云snova平台的监控机制和策略。完善的告警系统，能够获取当前服务端snova的运行情况，当snova某个指标波动超过正常阈值时进行警报提示，以及时止损，保证平台稳定运行和故障修复的及时介入。
之前组内一位大佬分享了一些关于系统性能优化方面的干货，这里我将它整理成文并且加入自己平时常用的一些工具和技巧。由于关于系统性能优化涉及的内容非常多，我会分几篇文章来分享。这次分享下定位系统层面问题的常用方法。
将智能网卡（NIC）置于白盒中 白盒是最受欢迎的商用现成（COTS）硬件，可以加入插件实现软件定义网络（SDN）和网络功能虚拟化（NFV）的各种计算和网络功能。但是随着SDN和NFV的发展，人们逐渐意
从2015年到2021年，移动数据流量将增长高达10倍以上。数据和新服务的需求大量涌现，数据和需求的来源不仅来自智能手机，还保留物联网（IoT）设备。电信运营商需要通过提供更快更新的服务来增强竞争力，
想让你的程序更快更稳，但是系统经常出各种 bug，无从下手？Java 性能调优全攻略来啦！
一款线上产品如果没有经过性能测试，那它就好比是一颗定时炸弹，你不知道它什么时候会出现问题，你也不清楚它能承受的极限在哪儿。有些性能问题是时间累积慢慢产生的，到了一定时间自然就爆炸了；而更多的性能问题是由访问量的波动导致的，例如，活动或者公司产品用户量上升；当然也有可能是一款产品上线后就半死不活，一直没有大访问量，所以还没有引发这颗定时炸弹。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
