并发数，线程数，吞吐量，每秒事务数（TPS）都是性能测试领域非常关键的数据和指标。
那么他们之间究竟是怎样的一个对应关系和内在联系？
测试时，我们经常容易将线程数等同于表述为并发数，这一表述正确吗？
本文就将对性能领域的这些关键概念做一次探讨。
文章可能会比较长，希望您保持耐心看完。
1. 走进开封菜，了解性能 ①老王开了家餐厅
我们的主角老王
餐厅里有4种不同身份的人员：
用户一次完整的用餐流程如下：
顾客到店小二处付款点餐 => 小二将订单转发给后厨 => 后厨与备菜工配合，取材完成烹饪后交给小二 => 小二上菜，顾客用餐。
假设所有顾客都不堂食而是打包带走，也就是不考虑用户用餐时间。餐厅完成一次订单的时间是多久？
订单时间 = 顾客点单时间 + 前台接收转发时间 + 后厨取材烹饪时间 + 后厨交给服务员，服务员上菜时间。
说白了就是每个流程的耗时相加。
假设以上时间分别为1，1，5，1（分钟），那么一次订单的完成时间就是8分钟。
②问题来了
餐厅当然不可能只有一个人就餐，否则老王不要带着小姨子跑路。
所以我们接下来看多人就餐的情况。
假设同一时间点上有两人
第一位用户与第一个场景一样，仍然是点单-下单-烹饪-上菜，8分钟后第一位顾客拿着打包的食物离开。
第二位用户则有所不同了。假设小二，厨师，备菜都只有一人，而且他们每个人同时只能处理一件事情。
那么第二位用户首先需要在点餐时等待小二1分钟，而后厨师烹饪第一位用户的菜时，没有任何人在为他服务。
我们来梳理一下这个过程中，每一分钟都发生了什么事情：
可以看到，两个顾客完成订单的总时长是13分钟。
继续推算我们发现，每增加一人总时长增加5分钟。
在当前的人员配置下，顾客越多，后来的顾客等待时间就越长。
③这还不是高峰期
如果餐厅在高峰时段只有两人用餐，那估计老王还得带着小姨子跑路。
实际一个运营得当的开封菜餐厅，在用餐高峰时段的顾客数可能高达百人。
那么问题来了，在某个普通工作日，12：00午饭时间，带着各种工牌的IT男女顾客蜂拥而至，餐厅瞬间挤进来一百人。
这个时候会发生什么？
现在餐厅已经完全服务不过来了，后续的顾客等的时间越来越长，最后一位可怜的顾客要等到差不多晚上8点才能吃到饭。
这显然是不可能的，实际上等了不到半个小时吃不上饭的顾客就都要走光了。
老王开始考虑如何应对营业高峰期的情况。
经过上面的分析，老王发现，增加各岗位人手无疑是最直观的解决办法！
我们可以计算一下人手增加的情况。假设把所有人员增加为2人配置：
那么很简单，2人就餐的情况下，由于所有人员并行服务，就餐的两名顾客可以同一时间点餐，等待烹饪，上菜后打包走人。