取决于处理器数和多线程技术，数个事务可以以线程
不过老王对于当前服务器的性能并不满意，就像对于餐厅一样，老王也针对这个应用服务思考了更多调优方案：
大厨的数量真的够吗？是不是要继续增加人数（CPU核数，服务器节点数-硬件调优）？
大厨的经验和技术到位吗？是不是要改聘更资深的大厨（改换具有更高频CPU的服务器-硬件调优；调整业务逻辑效率-逻辑调优）？
改良热门餐品的备菜策略？（利用数据库索引、缓存等技术-逻辑调优）
除了我们强调的调优重点，应用服务/后厨团队，其他部分也是有可能成为瓶颈，需要调优解决的，比如：
餐厅容量会不会无法容纳排队的客户？（服务器容量，线程池大小，最大连接数，内存空间）
小二的下单和上菜速度有没有成为掣肘？（网络带宽，路由效率等。对于数据密集型服务而言，网络带宽很可能成为瓶颈。）
等等
3. 下面是性能测试环节
接下来我们要讨论如何测试一套服务的性能。
线程数：要实现性能测试的一个必要条件，那就是我们必须要能模拟高峰期的访问量。这一点通过正常的应用客户端是很难办到的（比如web应用的客户端就是浏览器，你很难用浏览器并发向服务器发送大量请求）。
这里就需要性能测试工具来帮忙了，主流的性能测试工具比如
多线程式并发测试工具，顾名思义，会启动复数个线程，让每个线程独立向服务器端发出请求。
有时候我们在描述性能测试过程时，会将这个客户端的独立线程数表述为“并发数”。
但是注意，这里的“并发”指的是客户端并发，很简单，客户端能发出很多请求，服务器却未必能处理得了是不是？
并行数：那么服务器一次性能同时处理多少事务请求呢？
根据我们之前的讨论，同一时间节点上同时处理的事务数最大就是：CPU处理器数*服务器超线程倍率。
比如对于一个8核未超线程CPU，某时间节点上的同时处理的事务不会超过8个。类比于8个厨师，同一时间点上只能处理8份餐品。
而超线程技术就像是给厨师们来了一场“左右互搏”培训，让每个人都能一心二用，一次处理2份餐品。
这里我们描述的“同时8个”事务，就是“并行/平行”的含义。
并发数：注意上面我们讨论的“并行数”，不是"并发数"。否则我们直接看CPU核数就能确定并发数了。
并发数指的是一个时间段内
假设一个厨师平均2分钟做完一道菜，那么8个厨师2分钟完成8道菜，换算一下就是4道/分钟。
如果以分钟为单位进行统计，那么这个数字就是最终结果。
每秒事务数（TPS）：一般应用服务器的处理速度跟厨师做菜是不在一个数量级的，常见的事务请求在应用服务器端的处理时间以毫秒为单位计算。
所以测试性能时，我们更常用“1秒钟”来作为切片时间段。
一秒钟完成多少个事务请求，这个数据就是我们耳熟能详的“每秒事务数”。
这个指标翻译成英文就是TPS - Transaction Per Seconds。（也有用QPS - Query Per Seconds来统计的，其差异暂时不做讨论了）
每秒事务数，就是衡量服务器性能的最重要也是最直观指标。