杨亚洲，前滴滴出行专家工程师，现任OPPO文档数据库MongoDB负责人，负责数万亿级数据量文档数据库MongoDB内核研发、性能优化及运维工作，一直专注于分布式缓存、高性能服务端、数据库、中间件等相关研发。后续持续分享《MongoDB内核源码设计、性能优化、最佳运维实践》。

线上某IOT核心业务集群之前采用MySQL作为主存储数据库，随着业务规模的不断增加，MySQL已无法满足海量数据存储需求，业务面临着容量痛点、成本痛点问题、数据不均衡问题等。

400亿该业务迁移MongoDB后，同样的数据节省了极大的内存、CPU、磁盘成本，同时完美解决了容量痛点、数据不均衡痛点，并且实现了一定的性能提升。

此外，迁移时候的MySQL数据为400亿，3个月后的现在对应MongoDB集群数据已增长到1000亿，如果以1000亿数据规模等比例计算成本，实际成本节省比例会更高。迁移MongoDB后，除了解决业务痛点问题，同时也促进了业务的快速迭代开发，业务不在关心数据库容量痛点、数据不均衡痛点、成本痛点等问题。

该集群优化过程按照如下两个步骤优化：数据迁移开始前的提前预优化、迁移过程中瓶颈分析及优化、迁移完成后性能优化。

1、数据迁移开始前的提前预操作

和业务沟通确定，业务每条数据都携带有一个设备标识ssoid，同时业务查询更新等都是根据ssoid维度查询该设备下面的单条或者一批数据，因此片建选择ssoid。

为了充分散列数据到4个分片，因此选择hash分片方式，这样数据可以最大化散列，同时可以满足同一个ssoid数据落到同一个分片，保证查询效率。

MongoDB如果分片片建为hashed分片，则可以提前做预分片，这样就可以保证数据写进来的时候比较均衡的写入多个分片。预分片的好处可以规避非预分片情况下的chunk迁移问题，最大化提升写入性能。

Yield ea 1，装饰器使用的返回值，类似于 return方法 2，前置与后置处理分开

设置了装饰器之后，可以被其他用例调用，有使每个用例都有打开网页和默认关闭网页的作用

1. 装饰器使用的返回值，类似于 return方法

2. 使前置与后置处理分开

2，运行脚本-s,-d生成报告的目录，一般是一些json文件

3，下载allure生成工具，配置环境变量

性能测试其实就是通过自动化工具模拟多种正常、峰值以及异常负载来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，二者可结合使用。

性能指标主要有平均响应时间、90%响应时间、吞吐量、吞吐率，每秒事务数，以及服务器的资源使用率(CPU占比，mem内存占比等)等。当并发用户数超过300时，为了让测试数据更准确，可以考虑分布式压测，通过司令机控制几台奴隶机进行测试。

性能测试要先调试好脚本，主要考虑对脚本的数据参数化和添加断言。因为有些接口需要对业务逻辑或参数格式进行校验，为了能让所有线程数跑起来，需要将数据参数化。

数据参数化有这几种做法：

1. 可以将一些固定值改成随机函数;
2. 利用JDBC从数据库读取数据并关联变量；
3. Excal数据参数化，
4. 动态关联参数化，断言是为了判断用例是否

执行成功，并验证服务器的响应错误率。响应断言常用json断言，xml断言用的最少，

性能测试的目的是为了检验系统能否满足客户的性能需求，若性能需求无法满足时，则

要考虑对系统进行性能调优，一般用排除法：

1、首先考虑网络方面问题：使用ping命令查看与目标服务器的连接是否正常、传输速度的快慢。通过提升服务器的带宽，看响应时间是否相应降低。

2、考虑数据库的问题，可以单独去压测数据库，查看数据库的最大连接数和SQL语句的执行时间，索引命中率和sleep等待时间等

3、考虑 Apache中间件的问题，查看中间件设置的最大连接数是否合理，如果设置的连接数太小，会话数超过设定的最大连接数时会导致等待时间变长，出现响应超时情况

4、考虑服务器的硬件配置，如内存、CPU、men、磁盘读写速度等，可以用top命令来监控，也可以使用nmom工具来监控，nmom会把监控的数据形成表格形式，方便我们查看。

5、最后考虑开发代码写的好不好，处理时间长不长的问题。

举例：在我之前的公司，我们主要是会考虑用户操作使用比较频繁的模块，比如借贷，充值，投资模块，我们一般会通过增加并发数来压测，观察CPU、mem、磁盘读写、吞吐量和每秒事务数等性能指标，以前我老大要求我并发100个用户，我用 jmeter把线程数设为100，永久循环，持续时间半个小时，设置启动延退55，在Linux启用mmom工具监控服务器。

当我运行脚本的时候我看聚合报告90%的平均响应时间达到了6s，吞吐量也比较小，用top命令监控资源发现CPU差不多到了100%。于是我用 Navicat工具通过SQL命令show full processlist取当前运行的SQL语句，发现有许多语句用的是左关联，在查看了这条SQL语句的执行计划发现没有用索引，再查看了索引的命中率，命中率倒是还行看了下nmom生成的报告，发现CPU一直是处于爆满状态，其中主要是mysql的占比很大，这个时候我基本上判断数据库的问题。

于是我就照着前面的步骤再次压测，同样还是用nmom工具去监控CPU，mem网络等状态，这次我是主要在 Navicat上用命令去抓取SQL语句，还是一样有很多语句都是左关联，并发现很多空连接(sleep)，我就用 show global variable like"wait_time"命令查看了设置的休眠时间(等待时间)发现时间很长28800s，然后我就把这个休眠时间改成了20s，因为SQL语句使用了很多左连接，我就用 show variables like"tables_size"查看了临时表的空间大小、发现临时表只有16m，我将空间改成了1G再去压测了下，发现CPU只是降了10%左右，nmom报告上还是显示mysql占的CPU很大，然后运行的时候，用top命令监控，发现有的时候有很多mysq进程同时运行(因为没有设置连接池)，我就用命令查看了下mysql的最大连接数，因为SQL语句的执行速度还是挺快的，所以就把mysql的连接数调小到50，再去跑了一遍发现CPU降到了40%左右，并且其他的性能指标也都还不错。最后把聚合报告的数据以及nmom的数据整理成性能报告给老大，其实做接口性能主要就是用排除法个一个去排除，发现性能问题就要先解决了性能问题再压测，不然其他的问题也有可能是这个性能问题导致的所以接口性能基本上就是观察，各个性能指标都在范围之内就差不多了。

例外一种问法：简单介绍下你们公司的性能测试流程是怎么样的?

我们那个项目的性能做得不多，公司要求也不严格。

对于流程这块，首先就要对整个系统进行详细的分析，确定基本的测试范围，看下系统的哪些业务是需要做性能测试的，还有就是做那方面的性能测试，对于我们那个项目，当时就做了几个业务做了些简单的井发压测(稳定性)这块，像登录的，搜索查询，下单，还有就是购物车里面的几个接口都有做过，然后就是对各个业务场景进行详细的场景分析与设计，确定每个业务场景的并发数，是否需要设置集合点啊，压测时间是多长，还有各个业务场景的性能指标等等，场景设计这块基本上都是老大跟产品哪个一起弄的，我参与的不是太多。

上面把个场景设置好了之后，提交给我们，我们就是根据老大设置好的那些场景编写了基本的性能测试用例，其实做性能测试，我觉得前期最关键的还是业务场景一定要设计好，后期我们主要的任务就是准备各自任务需要用到的一些测试数据，搭建好测试环境，还有就是测试脚本设计与开发，执行，并生出测试报告，对于测试结果我们一般会简单的做个分析，如果没有什么问题，基本后期就写一个性能测试报告。流程大概就是这样的。

14.3  你们性能观察哪些指标，大概指标范围是怎么样的。

对于指标这块，业务方面的指标主要有：并发数，90%用户的平均响应时间

错误率，吞吐量/吞吐率这些，例外还需要关注服务器资源的使用情况，像：CPU的使用率、内存的占有率，磁盘IO，网络。

我们那个项目当时只针对，登录，搜索查询，下订单，购物车相关接口，支付等业务做了些简单的并发，压测这块，指标大概是这样的：

单基准业务并发测试登录，注册，查询1s以内，下订单，购物车相关接口，支付2s以内，混合业务性能：5s以内

响应时间：登录，注册业务<2s之内查询，下订单，购物车，支付业务<3s

充值，提现，查看充值日志，查看提现日志业务查询标的，<3s

投标，申请借款<5s

吞吐量/吞吐率：200左右请求/sec

%util: 磁盘一秒中有百分之多少的时间用于I/O操作，

% nowait：磁盘等待处理时间占比

带宽：<=系统带宽的30%，无丢包，无延迟，无阻塞

租用的服务器，一台数据库服务器，一台后端服务器

写过，主要是时间进度安排与工作安排，主要是环境，测试任务，测试需求，测试方法与策略，测试环境准备，测试通过的标准。

比如说原来我们一个项目性能测试时做了5天，那我们计划是，测试策略与用例编写一天，测试准备需要1天，测试执行2天，报告总结1天。

14.6  有没有写过性能测试报告，具体包括哪些内容

性能测试报告，需要每次 Jmeter压测完成的html报告的数据跟nmon工具监控的数据，整理出一份性能测试报告，性能测试报告，主要包含：

1，测试资源(环境，测试数据，表里面需要多少数据，测试工具)

2，测试设计(测试业务，测试类型，测试时间，并发用户数)

3，测试分析(每一个场景都需要分析)

4，测试结论(能不能上线，不上线的原因)

6，测试通过的标准，平均响应时间<5s，资源利用率<75%，事务失败率<5%

是指程序在申请内存后，无法释放已申请的内存空间，导致系统无法及时回收内存并且分配给其他进程使用。通常少次数的内存无法及时回收并不会到程序造成什么影响，但是如果在内存本身就比较少获取多次导致内存无法正常回收时，就会导致内存不够用，最终导致内存溢出。

1. 指程序申请内存时，没有足够的内存供申请者使用1M实际要占用2M内存，

就说分配的内存不够，导致内存溢出

1. 给了你一块存储int类型数据的存储空间，但是你却存储long类型的数据
2. 长期出现内存泄漏，导致系统内存越用越少，最终导致内存不够用，导致系统崩溃，出现OOM

指在一次性能测试过程中网络上传输的数据量的总和(单位应该KB)也可以这样说，

在单次业务中，客户端与服务器端进行的数据交互总量；对交互式应用来说，吞吐量指标反映服务器承受的压力。

并不是吞吐量越高越高，一个服务器的性能，要从多个方面去考虑：

90%用户的平均响应时间、错误率、吞吐量/吞吐量、CPU、内存、磁盘I/O、网络的占用情况，

吞吐量/传输时间，即单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量，它是衡量网络性能的重要指标。

通常情况下，吞吐率用“字节数秒”来衡量，当然，也可以用“请求数/秒”来衡量;

吞吐量/率和负载之间的关系:

1、上升阶段：吞吐量随着负载的增加而增加，吞吐量和负载成正比;

2、平稳阶段：吞吐量随着负载的增加而保持稳定，无太大变化或波动;

3、下降阶段：吞吐量随着负载的增加而下降，吞吐量和负载成反比;

总结：吞吐量/率干不过负载!!！

14.10  当你服务器满了之后，你们吞吐量和响应时间怎么变化的

吞吐量会所有下降，响应时间会变长

假设一个系统的业务有登录、浏览帖子、发送新帖、回复帖子，访问高峰是上午10点，日访问高峰PV约5208(含登录1300、浏览2706、发帖526、回帖676)，系统响应时间要求小于3秒，试计算此系统的TPS以及并发数。

如果分析业务量的数据是以PV来统计的，我们需要把PV转化为TPS。

PV的统计一般可以通过监控埋点或者统计访问日志统计得出。

说到PV还有个特殊的情况，叫 PeakY，指一天中PV数达到的高峰PV值。

通过一些监控系统，也可以直观看到统计数据。

实际上一个PV即一次对服务器的客户请求，可能还包含了很多资源请求，比如图片、样式JS信息、文字等。而浏览器具有资源缓存功能，下次访问同样资源将不会再从远程服务器上下载，这大大加快了响应速度。如果我们使用代理服务器访问外网资源时，多数代理服务器也会缓存这些静态数据。也就是说浏览器与服务器之间的动态数据的Size会小于静态数据。

所以浏览器是否缓存了静态数据对性能测试影响明显。我们在做性能测试时，其中就有许多用户可能是新用户，在他们的浏览器上还没有缓存这些静态数据，为了更准确的模拟用户请求，我们有必要不缓存这些静态内容.所以性能测试中是否缓存访问的静态资源要根据业务情况而定。

本例中，我们把一个请求放在一个事务中来统计服务器的响应时间。这么说，一个PV即是一个事务(每秒的PV量并不直接等同于TPS，因为一次客户请求可能包含了很多资源请求。如果我们不关心页面刷新时请求资源的耗时，此时我们就把每秒PV数等同于TPS)，比如一个功能页面(浏览帖子)每秒会有10个PV，那么此功能的TPS即为10。

业务量一般要取系统业务高峰的值，才能代表系统的实际处理能力，系统在10点的访问高峰PV约5208，那么这个时段的TPS =  ≈ 1.45吗?

答案是否定的，因为在一小时内的吞吐量未必是平均的。

如果我们采集到的业务量数据能够细分到每分钟，TPS就越准确。如果不能，可以按照二八原则。即80%的业务在20%的时间内完成，TPS=(5208*80%)/(3600*20%)≈5.8

1、由TPS进行估算 2、由在线活动用户数估算 3、根据经验估算

方法1：由TPS进行估算

因为TPS=事务数/时间，假设所有的事务都来自不同的用户，那么并发数=事务数=TPS * 时间。

其中，Vu(业务名称)表示此业务的虚拟用户数，即并发数。 RunTime是测试程序/脚本运行一次所消耗的时间，包括事务时间+非事务时间。 ThinkTime是模拟用户思考或者填写表单消耗的时间。

下面是发帖动作的测试脚本伪代码(T、TT、AT表示时间，单位为秒，AT一般都是非常小的，包含在事务时间中，可以忽略).Runtime=T1+...+T7; ThinkTime=TT1+TT2。

业内一般把 Think Time设为3秒。测试需求中要求响应时间小于3秒，我们就以3秒为阀值

可以看到两者之间的Vu数量相差巨大。由于一次迭代的时间会大于事务的响应时间，如果在估算时不把非事务消耗的时间加入进去，计算出来的12个并发用户在测试执行时很有可能无法达到TPS=5.8的目标。

由于我们计算Vu时，使用的是系统TPS(登录、浏览、发帖、回帖合计)，其中又以发帖业务消耗时间最长，所以计算出来的76个并发数实际上是系统业务的总并发数，需要按比例分配到各个业务。

方法2：在线活动用户数估算

1. 在线用户数的预估可以采取20%的系统用户数.例如某个系统的系统用户数有1000，则同时在线用户数据有可能达到200，或者预估200做参考。

在线用户数和并发用户数又存在着关系，即：平均并发用户数为C=NLTL为在线时长，T为考核时长例如考核时长为1天，即8小时，但是用户平均在线时长为2小时，则c=n*2/8

n为登录系统的用户数，L为登录的时常。例如一个系统有400个用户登录，然后每个用户登录大概停留2小时，则以一天8小时考核，算平均并发用户则为C=400*2/8

答：我们系统的TPS当时是根据PV值来计算的，就是通过查看系统访问日志来获取每个业务功能每天高峰期的PV值(也就是每天高峰期的时间段，有多少服务器的客户请求)，

当时的PV值大概在5000多

然后按照二八原则，即80%的业务在20%的时间内完成，TPS=(P80%)/(时间20%)≈5.6。算出来大概在5.6。

[具体的指标都是SE跟测试主管他们经过分析出来给到我们的。他们开会的时候大概跟我们说过估算方式，差不多是这样的……]

首先涉及到并发用户数可以从以下几个方面去做数据判断

1.系统用户数(注册用户数量)

2.在线用户数(平均每天大概有多少个用户要访问该系统，可以从系统日志从获得)

3.并发用户数(高峰期的时候的在线用户数量)

1. 在线用户数的预估可以采取20%的系统用户数。例如某个系统在系统用户数有1000，则同时 在线用户数据有可能达到200，或者预估200做参考
2. 在线用户数和并发用户数又存在着关系。即：平均并发用户数为C=NUTL为在线时长，

T为考核时长例如考核时长为1天，即8小时，但是用户平均在线时长为2小时，则c=n2/8

n为登录系统的用户数，L为登录的时常，例如一个系统有400个用户登录，然后每个用户登录 大概停留2小时，则以一天8小时考核，算平均并发用户则为c=400*2/8

答：就拿登录接口来讲吧

我们的并发数是根据注册用户数量及每天在线用户数综合来估算的，我们系统当时注册用户数量大概是在70多万的样子，不过这里其实有一些僵尸用户，真正的用户大概在60%的样子，也就是差不多，46万多一点，通过查看系统访问日志，高峰期的时候每天在线数,用户数量大概差不多在52000多点吧，按52000估算，每个用户停留时间大概在20分钟左右，大概平均每天同时在线用户数量在2145多。其中登录业务的占比大概在10%的样子，同时在登录的大概80%的比例计算，登录接口大概设置的并发数在172多的样子，查询业务的占比大概在30%，查询接口大概设置的井发数在510的样子，下单业务大概占比在20%，下单接口的井发数设定在345的样子。

[具体的指标都是SE跟测试主管他们经过分析出来给到我们的。他们开会的时候大概跟我们说过估算方式，差不多是这样的...]

14.14  你们吞吐量是多少，响应时间是多少，你设置了多少井发?

登录：吞吐量大概在13.5/sec响应时间<1s，设置的并发数180个并发数。

查询：吞吐量大概在36/sec响应时间<3s，设置的并发数500个并发数。

下单：吞吐量大根在25.6/sec响应时间<3s，设置的并发数350个并发。

cpu大概在60%多点，内存大概占比在65%的样子。

部分接口有做过稳定性测试。具体怎么做的?

稳定性测试主要就是看某个业务在高并发情况下是否能持续稳定运行嘛，当时大部分的核心业务都有做过稳定性的，这个需是把并发数设置为峰值，然后循环次数设置为永远，例外要开启调度器，调度器中的持续时间设定为3600秒，让它持续压测1个小时。看下接口的各项性能指标的变化，是否在预期的指标范围之内。

并发数，按群内最大人数计算，利用二八原则，5000 * 80%=4000，并发数的峰值为4000

14.18  微信群里面发送红包，5000个人群，只能3000个人能抢到，你怎么设计并发数的峰值

并发数，按群内最大人数计算，利用二八原则，5000 * 80%=4000，并发数的峰值为4000

线程数设置20个，循环次数40

这个需要用到自定义线程组，自定义线程组最大的好处就在于做压测的时候，可以设置一些复杂的业务场景，具体设置的话，就是.....

1、使用存储过程来实现

2、可以通过 JMeter来实现，调用注册接口，线程数设置为500，账号，密码可以通过 JMeter中的随机函数 randomString()，random()函数结合计数器来实现。

这里一般我会采用排查发，首先考虑软件优化问题，之后考虑硬件问题，思路大概是这样的

1、首先考虑中间件(tomcat，Apache的连接数的问题)，可以尝试增加连接数，看是否变化。

2、例外还有就是数据库的连接数问可题，也可以尝试增加，看是否有变化。

3、要不就是看数据库的访问效率问题，这里要考虑数据库的操作是否添加索引，如果没有添加索引，可以让开发优化下数据库的访问速度，添加索引，或者优化sql语句。

4、再一个就可以尝试考虑后台代码的架构设计是否合理，代码算法是否足够优化。

5、如果以上问题都不能解决，那么只能考虑增加服务器的CPU内存，或者增加网络带宽，看响应时间是否可以得到优化。

大概的思路差不多就是这样的吧。

1、如果是所有请求的数据报错，那肯定是脚本问题，认真检查脚本参数。

2、如果只是部分请求报错，那估计是性能可题了。

响应时间过长(排除法) -用户体验不好

1，网络情况(提升带宽)

8，sql语句执行时间

2、运行sql语句是否需要sq优化

低于0.1%比较好，低于0.01%分配比校多，适当减少缓存空间大小

2，很多问题，都是同一个问题导致，需要一个个去排除优化，解决

资源使用率不足：(系统薄弱的位置)

资源使用率过高：(系统会崩溃)

那我们就需要考虑分布式压测，那需要准备几台测试机，

master机器要设置。。。。

奴隶机要设置。。。。。

也可以租用云测平台进行测试

14.26  如果用户并发要慢慢加载，你怎么设置的

设置并发数的时候，我们会设置启动时间，比如说设置50个并发用户数就是50个线程组，

启动时间会设置成10秒，让用户慢慢启动起来

1，并发用户数越多，响应时间越长

2，并发用户数越多，吞吐量会一直，增加，增加到一个临界点(系统瓶颈后)，不再增加，有少许的回落

 文章到这里就结束了，各位铁汁如果有什么觉得不对的可以发在评论区咱们来讨论哈，
听说关注我并三连的铁汁都已经升职加薪暴富了哦！！！！

在技术面试中都会对面试者硬实力进行考查呢，主要从2个角度进行：

• 宽度：掌握的知识是否全面

• 深度：掌握的能力是否深入

宽度在一定程度上决定了你是否能够进入一家公司，深度则决定了你offer的等级。对于BAT，甚至更好的公司来说，有时候深度甚至可能决定你是否能够进入这家公司。
在过去几个月里，经过深度思考和总结最终整理出了如下知识点详细解析，只要你认真看完，并牢记在心里，但是要掌握还得在实践中使用。

• JVM与调优 20 题及答案解析

• 多线程&并发编程 22 题及答案解析

• Nginx 面试题及答案解析

• 数据结构与算法 面试题及答案解析

• linux 面试题及答案解析

1. Java语言有哪些特点

2. 面向对象和面向过程的区别

3. 八种基本数据类型的大小，以及他们的封装类

4. Java自动装箱与拆箱

5. Java的四种引用，强弱软虚

6. Java创建对象有几种方式？

7. 有没有可能两个不相等的对象有相同的hashcode

8. 深拷贝和浅拷贝的区别是什么?

9. 3*，一经查实，将立刻删除涉嫌侵权内容。