03 | 系统设计目标（一）：如何提升系统性能？

Sep 23, 2019

03 | 系统设计目标（一）：如何提升系统性能？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

03 | 系统设计目标（一）：如何提升系统性能？

2019-09-23 唐扬来自北京

《高并发系统设计40问》

课程介绍



讲述：唐扬

时长14:56大小13.67M



提到互联网系统设计，你可能听到最多的词儿就是“三高”，也就是“高并发”“高性能”“高可用”，它们是互联网系统架构设计永恒的主题。在前两节课中，我带你了解了高并发系统设计的含义，意义以及分层设计原则，接下来，我想带你整体了解一下高并发系统设计的目标，然后在此基础上，进入我们今天的话题：如何提升系统的性能？
高并发系统设计的三大目标：高性能、高可用、可扩展高并发，是指运用设计手段让系统能够处理更多的用户并发请求，也就是承担更大的流量。它是一切架构设计的背景和前提，脱离了它去谈性能和可用性是没有意义的。很显然嘛，你在每秒一次请求和每秒一万次请求，两种不同的场景下，分别做到毫秒级响应时间和五个九（99.999%）的可用性，无论是设计难度还是方案的复杂度，都不是一个级别的。
而性能和可用性，是我们实现高并发系统设计必须考虑的因素。
性能反映了系统的使用体验，想象一下，同样承担每秒一万次请求的两个系统，一个响应时间是毫秒级，一个响应时间在秒级别，它们带给用户的体验肯定是不同的。
可用性则表示系统可以正常服务用户的时间。我们再类比一下，还是两个承担每秒一万次的系统，一个可以做到全年不停机、无故障，一个隔三差五宕机维护，如果你是用户，你会选择使用哪一个系统呢？答案不言而喻。
另一个耳熟能详的名词叫“可扩展性”，它同样是高并发系统设计需要考虑的因素。为什么呢？我来举一个具体的例子。
流量分为平时流量和峰值流量两种，峰值流量可能会是平时流量的几倍甚至几十倍，在应对峰值流量的时候，我们通常需要在架构和方案上做更多的准备。这就是淘宝会花费大半年的时间准备双十一，也是在面对“明星离婚”等热点事件时，看起来无懈可击的微博系统还是会出现服务不可用的原因。而易于扩展的系统能在短时间内迅速完成扩容，更加平稳地承担峰值流量。
高性能、高可用和可扩展，是我们在做高并发系统设计时追求的三个目标，我会用三节课的时间，带你了解在高并发大流量下如何设计高性能、高可用和易于扩展的系统。
了解完这些内容之后，我们正式进入今天的话题：如何提升系统的性能？
性能优化原则“天下武功，唯快不破”。性能是系统设计成功与否的关键，实现高性能也是对程序员个人能力的挑战。不过在了解实现高性能的方法之前，我们先明确一下性能优化的原则。
首先，性能优化一定不能盲目，一定是问题导向的。脱离了问题，盲目地提早优化会增加系统的复杂度，浪费开发人员的时间，也因为某些优化可能会对业务上有些折中的考虑，所以也会损伤业务。
其次，性能优化也遵循“八二原则”，即你可以用 20% 的精力解决 80% 的性能问题。所以我们在优化过程中一定要抓住主要矛盾，优先优化主要的性能瓶颈点。
再次，性能优化也要有数据支撑。在优化过程中，你要时刻了解你的优化让响应时间减少了多少，提升了多少的吞吐量。
最后，性能优化的过程是持续的。高并发的系统通常是业务逻辑相对复杂的系统，那么在这类系统中出现的性能问题通常也会有多方面的原因。因此，我们在做性能优化的时候要明确目标，比方说，支撑每秒 1 万次请求的吞吐量下响应时间在 10ms，那么我们就需要持续不断地寻找性能瓶颈，制定优化方案，直到达到目标为止。
在以上四个原则的指引下，掌握常见性能问题的排查方式和优化手段，就一定能让你在设计高并发系统时更加游刃有余。
性能的度量指标性能优化的第三点原则中提到，对于性能我们需要有度量的标准，有了数据才能明确目前存在的性能问题，也能够用数据来评估性能优化的效果。所以明确性能的度量指标十分重要。
一般来说，度量性能的指标是系统接口的响应时间，但是单次的响应时间是没有意义的，你需要知道一段时间的性能情况是什么样的。所以，我们需要收集这段时间的响应时间数据，然后依据一些统计方法计算出特征值，这些特征值就能够代表这段时间的性能情况。我们常见的特征值有以下几类。
平均值
顾名思义，平均值是把这段时间所有请求的响应时间数据相加，再除以总请求数。平均值可以在一定程度上反应这段时间的性能，但它敏感度比较差，如果这段时间有少量慢请求时，在平均值上并不能如实地反应。
举个例子，假设我们在 30s 内有 10000 次请求，每次请求的响应时间都是 1ms，那么这段时间响应时间平均值也是 1ms。这时，当其中 100 次请求的响应时间变成了 100ms，那么整体的响应时间是 (100 * 100 + 9900 * 1) / 10000 = 1.99ms。你看，虽然从平均值上来看仅仅增加了不到 1ms，但是实际情况是有 1% 的请求（100/10000）的响应时间已经增加了 100 倍。所以，平均值对于度量性能来说只能作为一个参考。
最大值
这个更好理解，就是这段时间内所有请求响应时间最长的值，但它的问题又在于过于敏感了。
还拿上面的例子来说，如果 10000 次请求中只有一次请求的响应时间达到 100ms，那么这段时间请求的响应耗时的最大值就是 100ms，性能损耗为原先的百分之一，这种说法明显是不准确的。
分位值
分位值有很多种，比如 90 分位、95 分位、75 分位。以 90 分位为例，我们把这段时间请求的响应时间从小到大排序，假如一共有 100 个请求，那么排在第 90 位的响应时间就是 90 分位值。分位值排除了偶发极慢请求对于数据的影响，能够很好地反应这段时间的性能情况，分位值越大，对于慢请求的影响就越敏感。
在我来看，分位值是最适合作为时间段内，响应时间统计值来使用的，在实际工作中也应用最多。除此之外，平均值也可以作为一个参考值来使用。
我在上面提到，脱离了并发来谈性能是没有意义的，我们通常使用吞吐量或者响应时间来度量并发和流量，使用吞吐量的情况会更多一些。但是你要知道，这两个指标是呈倒数关系的。
这很好理解，响应时间 1s 时，吞吐量是每秒 1 次，响应时间缩短到 10ms，那么吞吐量就上升到每秒 100 次。所以，一般我们度量性能时都会同时兼顾吞吐量和响应时间，比如我们设立性能优化的目标时通常会这样表述：在每秒 1 万次的请求量下，响应时间 99 分位值在 10ms 以下。
那么，响应时间究竟控制在多长时间比较合适呢？这个不能一概而论。
从用户使用体验的角度来看，200ms 是第一个分界点：接口的响应时间在 200ms 之内，用户是感觉不到延迟的，就像是瞬时发生的一样。而 1s 是另外一个分界点：接口的响应时间在 1s 之内时，虽然用户可以感受到一些延迟，但却是可以接受的，超过 1s 之后用户就会有明显等待的感觉，等待时间越长，用户的使用体验就越差。所以，健康系统的 99 分位值的响应时间通常需要控制在 200ms 之内，而不超过 1s 的请求占比要在 99.99% 以上。
现在你了解了性能的度量指标，那我们再来看一看，随着并发的增长我们实现高性能的思路是怎样的。
高并发下的性能优化假如说，你现在有一个系统，这个系统中处理核心只有一个，执行的任务的响应时间都在 10ms，它的吞吐量是在每秒 100 次。那么我们如何来优化性能从而提高系统的并发能力呢？主要有两种思路：一种是提高系统的处理核心数，另一种是减少单次任务的响应时间。
1. 提高系统的处理核心数
提高系统的处理核心数就是增加系统的并行处理能力，这个思路是优化性能最简单的途径。拿上一个例子来说，你可以把系统的处理核心数增加为两个，并且增加一个进程，让这两个进程跑在不同的核心上。这样从理论上，你系统的吞吐量可以增加一倍。当然了，在这种情况下，吞吐量和响应时间就不是倒数关系了，而是：吞吐量 = 并发进程数 / 响应时间。
计算机领域的阿姆达尔定律（Amdahl’s law）是吉恩·阿姆达尔在 1967 年提出的。它描述了并发进程数与响应时间之间的关系，含义是在固定负载下，并行计算的加速比，也就是并行化之后效率提升情况，可以用下面公式来表示：
(Ws + Wp) / (Ws + Wp/s)
其中，Ws 表示任务中的串行计算量，Wp 表示任务中的并行计算量，s 表示并行进程数。从这个公式我们可以推导出另外一个公式：
1/(1-p+p/s)
其中，s 还是表示并行进程数，p 表示任务中并行部分的占比。当 p 为 1 时，也就是完全并行时，加速比与并行进程数相等；当 p 为 0 时，即完全串行时，加速比为 1，也就是说完全无加速；当 s 趋近于无穷大的时候，加速比就等于 1/(1-p)，你可以看到它完全和 p 成正比。特别是，当 p 为 1 时，加速比趋近于无穷大。
以上公式的推导过程有些复杂，你只需要记住结论就好了。
我们似乎找到了解决问题的银弹，是不是无限制地增加处理核心数就能无限制地提升性能，从而提升系统处理高并发的能力呢？很遗憾，随着并发进程数的增加，并行的任务对于系统资源的争抢也会愈发严重。在某一个临界点上继续增加并发进程数，反而会造成系统性能的下降，这就是性能测试中的拐点模型。
从图中你可以发现，并发用户数处于轻压力区时，响应时间平稳，吞吐量和并发用户数线性相关。而当并发用户数处于重压力区时，系统资源利用率到达极限，吞吐量开始有下降的趋势，响应时间也会略有上升。这个时候，再对系统增加压力，系统就进入拐点区，处于超负荷状态，吞吐量下降，响应时间大幅度上升。
所以我们在评估系统性能时通常需要做压力测试，目的就是找到系统的“拐点”，从而知道系统的承载能力，也便于找到系统的瓶颈，持续优化系统性能。
说完了提升并行能力，我们再看看优化性能的另一种方式：减少单次任务响应时间。
2. 减少单次任务响应时间
想要减少任务的响应时间，首先要看你的系统是 CPU 密集型还是 IO 密集型的，因为不同类型的系统性能优化方式不尽相同。
CPU 密集型系统中，需要处理大量的 CPU 运算，那么选用更高效的算法或者减少运算次数就是这类系统重要的优化手段。比方说，如果系统的主要任务是计算 Hash 值，那么这时选用更高性能的 Hash 算法就可以大大提升系统的性能。发现这类问题的主要方式，是通过一些 Profile 工具来找到消耗 CPU 时间最多的方法或者模块，比如 Linux 的 perf、eBPF 等。
IO 密集型系统指的是系统的大部分操作是在等待 IO 完成，这里 IO 指的是磁盘 IO 和网络 IO。我们熟知的系统大部分都属于 IO 密集型，比如数据库系统、缓存系统、Web 系统。这类系统的性能瓶颈可能出在系统内部，也可能是依赖的其他系统，而发现这类性能瓶颈的手段主要有两类。
第一类是采用工具，Linux 的工具集很丰富，完全可以满足你的优化需要，比如网络协议栈、网卡、磁盘、文件系统、内存，等等。这些工具的用法很多，你可以在排查问题的过程中逐渐积累。除此之外呢，一些开发语言还有针对语言特性的分析工具，比如说 Java 语言就有其专属的内存分析工具。
另外一类手段就是可以通过监控来发现性能问题。在监控中我们可以对任务的每一个步骤做分时的统计，从而找到任务的哪一步消耗了更多的时间。这一部分在演进篇中会有专门的介绍，这里就不再展开了。
那么找到了系统的瓶颈点，我们要如何优化呢？优化方案会随着问题的不同而不同。比方说，如果是数据库访问慢，那么就要看是不是有锁表的情况、是不是有全表扫描、索引加的是否合适、是否有 JOIN 操作、需不需要加缓存，等等；如果是网络的问题，就要看网络的参数是否有优化的空间，抓包来看是否有大量的超时重传，网卡是否有大量丢包等。
总而言之，“兵来将挡水来土掩”，我们需要制定不同的性能优化方案来应对不同的性能问题。
课程小结今天，我带你了解了性能的原则、度量指标，以及在高并发下优化性能的基本思路。性能优化是一个很大的话题，只用短短一讲是完全不够的，所以我会在后面的课程中详细介绍其中的某些方面，比方说我们如何用缓存优化系统的读取性能，如何使用消息队列优化系统的写入性能等等。
有时候你在遇到性能问题的时候会束手无策，从今天的课程中你可以得到一些启示，在这里我给你总结出几点：
数据优先，你做一个新的系统在上线之前一定要把性能监控系统做好；
掌握一些性能优化工具和方法，这就需要在工作中不断地积累；
计算机基础知识很重要，比如说网络知识、操作系统知识等等，掌握了基础知识才能让你在优化过程中抓住性能问题的关键，也能在性能优化过程中游刃有余。
一课一思在课程中我们提到了一些性能优化的原则和基本的思考点，那么你在日常工作中有哪些性能优化的手段和经验呢？欢迎在留言区与我分享你的经验。
最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 37

提建议

02 | 架构分层：我们为什么一定要这么做？

04 | 系统设计目标（二）：系统怎样做到高可用？

 写留言

精选留言(63)

肖大保健
2019-09-23
讲的太宽泛了，请具体实例化，这种文章在网上到处能找到，建议多点干货
编辑回复: 基础篇会偏理论知识多一些，主要是想给大家一些高并发知识的概要介绍，这部分案例偏少，我们在做课程设计的时候考虑到了，从我的角度，这部分内容是必讲的，并且我敢说这种讲法你在外面是找不到的，都是我的经验总结。案例我们会从演进篇开始加入，思路是从一个简易系统到一个复杂系统的高并发演进之路。我很想把这个内容做好，所以类似的反馈还请大家都提给我，我和极客时间团队讨论后会根据情况做优化。之所以把这个留言放出来也是这样，希望能得到大家的监督，我们一起学好高并发知识。分享就是学习，从和大家的交流离我也在成长。
共 9 条评论
183
Jxin
2019-09-24
1.业务价值->承载高并发->性能优化。一切的前提是业务价值需要。如果没有足够的价值，那么可读性才是第一，性能在需要的地方是no.1，但不需要的地方可能就是倒数第一稞。当下技术框架出来的软件差不到哪去，没有这种及时响应诉求的地方，削峰下慢慢跑就是了。（工作需要，常在缺少价值的地方着手性能优化，让我对这种就为个数字的操作很反感。要知道，异步，并发编程，逻辑缓存，算法真的会加剧系统的复杂度，得不偿失。如果没那个价值，简单才是王道） 2.提高并发度。要么加硬件，要么降低服务响应时间。做为开发，我们的目光更聚焦在降低响应时间这块。 1.采用非阻塞的rpc调用（高效的远端请求模式，采用容器的覆盖网络我认为也算） 2.将计算密集和io密集的的逻辑分割开，单独线程池，调整线程比例压榨单机性能（或者说找拐点）。 3.做缓存，io耗时的缓存和计算耗时的缓存（多级缓存，数据压缩降低带宽）。 4.采用享元模式，用好对象池和本地线程空间，尽量减少对象创建与销毁的开销，提高复用。 5.业务拆分，像状态变化后的外部系统通知，业务监控，es或solr等副本数据同步等操作，无需在主流程中做的事都拆掉。走canal监听表数据变化，推mq保最终一致的方式从业务项目完全解偶出来。 6.fork_join，分而治之的处理大任务。并发编程，采用多线程并行的方式处理业务。（规避伪共享，减小锁力度，采用合适的锁）。 7.数据库配置优化，查询优化。（存储优化比较头疼，毕竟不按业务拆单点跑不掉，单点性能就要命。基本只能内存库先行，后台同步数据做持久。然后内存库多副本，自修复，保留一系列自修复失败的修复手段）
展开
作者回复: 给你点赞👍
共 10 条评论
116
平步青云
2019-09-24
既然老师愿意把这门课做好，作为学员提几点建议： 1.每一章都会有一个中心，几个侧重点，建议关键部分文字加粗或者字号加大一点，让重心更醒目。一遍看下来，几乎啥都没记住。 2.条理清晰，有时候你会发现，用1.2.3这种编号作用非常明显。这点得到做的挺好的，我都购买的有课程。 3.技术文章，理论讲太多，都觉得是鸡汤，看了就忘，或者说作用不大，理论大家能查阅资料，也算是理解一星半点。大家的问题都在于没把理论作用于实践中，如果每一章讲完理论后能够以实际应用辅助讲一下，可以说事半功倍。 4.我说话很直接，真正的高手也不会购买课程，购买课程的也是大家在这块有短板，希望通过这门课解决一些项目中的问题。按照2/8原则，百分之八十的人项目中都没有大并发，这种系统设计和运用，大家缺乏经验。讲解时候，浅显易懂，案例分享很关键，百分之八十人看懂了，能应用了，那这门课非常成功了。 5.希望高手之间多讨论或者辩论，其实在你们的讨论中，可以学到很多，开拓视野，举一反三。希望评论中只要不是骂人，违反国家政策，涉及到问题本身讨论的，尽量显示出来。
展开
作者回复: 好的后面演进篇中会有案例
43
无形
2019-10-31
之前做广告检索遇到的问题，倒排索引存在Redis，每次都要请求Redis，但是并发时，Redis连接数太大，甚至打开文件数过大，后采用Redis连接池，Redis连接数得到控制，而且响应更快，后来随着并发数的增大，连接池资源耗尽，而且Redis也有并发限制，数据传输导致大量占用带宽，响应时间更久，因此，又使用了本地缓存，每次请求先请求本地缓存，找不到再请求Redis，缓存到本地，缓存更新时通过消息队列来通知程序更新本地缓存，这样节省了大量的和Redis之间的请求耗时和带宽占用，性能有了数倍的提升。后面还有很多优化，性能优化不是一蹴而就的，每个阶段面对的场景是不一样的，需要找到每个瓶颈点针对性的优化
展开
作者回复: 赞，经验丰富老司机：）
共 12 条评论
29
Cola_
2019-09-23
高并发：高性能（响应时间）、高可用（down机、故障、维护）、可扩展（应急扩容）响应时间（平均值、最大值、分位值），响应为1s，吞吐量为每秒1次，响应缩短到10ms，吞吐量上升到每秒100次，从用户体验来说：200ms分界点，1s为另一个分界点，健康系统的99分位值的响应时间控制在200ms以内，不超过1s的请求占比要超过99.99% 高并发下的性能优化手段： 1.提高系统的处理核心数（吞吐量=核心数(并发进程数)/响应时间(s)）但并非无限增加核心数就可以增加吞吐量，随着进程数增加，并行的任务对于资源的争夺也增加，在某个临界点，进程增加导致系统的性能下降，这就是性能测试中的拐点模型，所以在评估系统性能时，需要做压力测试，找到拐点 2.减少单次任务响应时间 cpu密集型：优化算法 io密集型：1.采用工具，linux的工具集 2.通过监控，对任务的每一个步骤做分时统计，从而找到任务中哪一步小号消耗了更多的时间
展开
作者回复: 👍👍
共 2 条评论
25
钱
2020-04-06
哈哈，看评论“真正的高手也不会购买课程”，扎心啦！😄，不过事实也应该是如此的。我猜测一下，真正的高手在干嘛！第一技术负责人，负责一些核心项目第二技术专家，写书出专栏第三开源项目贡献者，参与和贡献过知名的开源项目第四技术社区或知名项目的领导者第五知名公司CTO，在用技术改变世界第六技术大神一门语言或一个框架的开创者不过根据2/8原则，猜测80%的人都不在这个范围内，这就是极客时间存在的意义。我想表达啥呢？极客时间对我帮助还是非常大的，我也从业多年，不过比较遗憾没到高手的行列。技术是我养家糊口的工具，跟一些作者年龄相近实力却相差甚远，花几十元和他们聊聊，基本收获都是大于付出的钱的。相信极客时间的过滤功能，希望自己能够早日不用再购买课程。😅
展开
作者回复: 加油~
共 3 条评论
15
星星
2019-09-25
老师你好，高并发有什么好的模拟工具？
作者回复: 一般使用线上流量引流的工具，tcpcopy, goreplay
共 2 条评论
12
吃饭饭
2019-09-23
老师能普及一下常见的术语吗？比如 QPS 和 TPS。日常优化不从服务器谈，只说 Review 的一些常识，避免循环调用，热点数据提前预热，可以加入利用内存缓存一些配置数据等等，不知道理解的对不对：）
作者回复: QPS指的是每秒查询请求数；TPS指的是每秒执行事务数，偏向于写请求。这些常识虽然有些零散，不过是正确的：）
7
长期规划
2019-12-24
从全局看，高性能需要全链路检查，常用方法是拆分，精简，换硬件等。拆分如读写分离，分片等，精简如进程→线程→协程，HTTP→RPC，换硬件如内存替换硬盘等。从编程角度，还可以使用合适的数据结构和算法
作者回复: 👍
6
sun
2019-09-26
日常工作中，项目优化的不够好，那就对部门进行优化⁽⁽ଘ😇ଓ⁾⁾
作者回复: 这。。
共 3 条评论
6
高源
2019-09-24
从小到大从浅入深，老师我最想知道的是开发的系统如何找出程序瓶颈，问题具体出现在哪，用什么工具或者方法解决了，从而在后期有机会设计高并发高可用系统的时候根据实际情况来下手
作者回复: 找问题的话主要有三个方法，监控，工具和压测压测和监控后面会有介绍，工具要依靠自己的积累，在文章中也有介绍
共 2 条评论
6
Geek_Rex
2019-09-24
请问通过什么工具可以测试WEBAPI的响应时间？
作者回复: access log有记录响应时间的，可以收集起来做成监控
5
小袁
2020-03-01
大家不要觉得虚，看这些理论的时候，多想想自己负责的系统犯过什么傻逼的问题就能举一反三。适逢公司的架构不够用，我先过来重温一下这些理论再考虑优化。
作者回复: 谢谢~
5
饭团
2019-09-23
嗯，老师说的数据优先，我觉得最重要！一切的优化前提都是在数据的支撑下进行！请问老师一般系统的性能指标都问怎么统计？比如最大响应时间，平均响应时间！分位值统计方式，我们可以在请求开始和请求返回时做时间统计！写入log之后定时分析log得到！系统cpu指标，内存指标，io指标这种是定时通过系统函数获取信息统计吗？其实我想问老师的是，一般高并发系统都统计系统的哪些指标？
展开
作者回复: 这个在后面课程会有介绍哦：）
共 3 条评论
4
Maxwell
2019-09-23
老师，在高并发时涉及到要更改公用的值，考虑到数据库的并发量的瓶颈，采用缓存来抗并发，但此时数据一致性的保证一般什么方案？
作者回复: 可以考虑cache aside的方式来使用缓存，后面会介绍：）
3
下个目标45k
2020-11-24
排查性能问题思维框架 1. 问题导向，首先要做的就是定位到瓶颈在哪里，解决问题最重要的是弄清楚问题本身。java web可以使用arthas非常方便。 2. 二八原则，系统性能瓶颈数量大概率会存在多个，抓住主要矛盾。 3. 数据，数据指标不会骗人，直觉是不准的。 4. 持续，随着项目在不断迭代意味着性能瓶颈点也在不断变化，需要持续性的进行观察。以上四点其实是环环相扣，缺一不可。是不是有点精益创业方法论的感觉了😂 上面有朋友提到文章理论知识过多缺少实践，不必心急。理论是道，实践是术，理论实践结合是最好的，但前提是对于理论我们有深入思考理解，否则就有点搞错主次了。有句话形容的很好，道为根本术为道之动。让我们掌握基础的理论，形成自己的思维框架，我想这才是作者的初衷。
展开
共 1 条评论
3
Luciano李鑫
2019-09-25
“我们通常使用吞吐量或者同时在线用户数来度量并发和流量，使用吞吐量的情况会更多一些。但是你要知道，这两个指标是呈倒数关系” 这个地方是不是有问题，吞吐量和在线用户数是倒数关系？？
作者回复: 表述不清楚，应该是吞吐量和响应时间
2
sipom
2020-03-22
代码层：采用高效算法，避免低效代码；应用层：多线程/多进程并发；数据库/缓存：分库分表并发；系统层：多节点、多套系统并发/负载均衡
作者回复: 👍
2
M
2019-11-20
老师问一下，目前做线上压测有什么工具吗，或者通常用什么方法来做呢？
作者回复: 压测在32节中讲到
共 2 条评论
1
billow
2019-11-10
说个以前看过的一篇讲高性能server开发需要注意的点：上下文切换数据拷贝内存分配锁竞争
1

