而后来的客人可以看作两条并行的线，那么100顾客的用餐时间就很自然的减半了。
看到这里，终于出现“并行”的概念了。
④继续调优
通过double人员配置，老王成功的使得用餐高峰期的服务能力提高了一倍，但这还不够。这种情况下，服务100顾客仍需差不多4个小时。
老王再次思考整个服务团队的配置和各环节处理能力，他发现，其瓶颈就在于“后厨”。顾客的等待时间，大部分都是在等待烹饪。
那么增加后厨能力就是重中之重，老王继续做了一系列措施：
再次double大厨人数，现在厨师们四个人同时并行做菜。
让备菜员提前将热门食材准备好。
聘请更有经验的大厨，每个餐品烹饪时间更快，加上提前备菜，整个配餐时间缩短到2分钟。
将点餐的过程改为使用手机小程序下单，让小二专注于上菜。
整个团队配置变为：
如此配置之下，这家开封菜终于可以在1小时之内就完成对100人顾客的就餐服务了！
2. 这并不是一篇餐饮管理文章
再继续讨论餐厅的服务能力调优，这可能就要变成一片餐饮博文了。
不过相信敏锐的你能看出来，第一部分我们的讨论里，包含了大量与服务器性能相似的概念。
恰好，老王
这家网站的一次典型事务请求链路是这样的：
你别说，还真挺像用餐流程的吧。
而且就像多人用餐的场景一样，这个网站同样也有多用户请求的情况：
当一条请求从客户端发起时，它遵循着以上的线路传递，线性完成。
老王发现，这家网站的性能关键，在于应用服务器上。就像餐厅的服务能力，主要取决于后厨团队一样。
当多个客户端同时发起请求时，服务器必须具备一定的“并行”能力，否则后续进来请求会排队而且可能超时。
说到这呢，虽然上图我们画的是一个
而主流编程语言都有“多线程编程”的概念，其目的就在于合理的调度任务，将CPU的所有处理器充分的利用起来。
也就是说我们可以认为，这套应用服务本身就有不止一个“大厨”在烹饪。