使用 Python SimPy 进行离散事件模拟【02】 — 识别性能指标（队列和利用率）并可视化结果

        继续我们所做的模拟餐馆系统的工作，在本章中，我们想与您讨论如何识别性能指标，以便我们可以通过开发的模型有效地评估我们的系统。在此过程中，我们将深入了解队列和利用率的概念，因为这些术语与离散事件系统性能密切相关。

二、进入基础模型：模拟披萨和咖啡餐馆 🍕🥤

注意：以下研究案例叙述和代码可以通过 GitHub 存储库访问。

插图由 Greggs 提供

想象一下，你在城市主干道的拐角处经营着一家咖啡和披萨店。你想观察餐馆的日常运营是如何形成的，因为你被告知，在某些情况下，等待时间太长，或者一些顾客抱怨为什么桌子总是被占用。

然后，您设法从直接观察中收集了一些数据。一些数据，如处理时间、客户到达间隔时间，直到收集客户偏好为止。现在使用离散事件模拟，您可以尝试在更具定量代表性的模型中实际了解餐馆的运作方式。

上一章 快速回顾：基本 DES 模型构建

我们绝对需要从第 1 章中断的地方重新开始，其中我们定义了输入参数，映射和建模了餐厅内的底层流程活动，并为餐厅构建了主要的模拟代码。为了确保您正确地开始本章，请确保您已经熟悉第 1 章的基本 python 代码。但是，我已经导入了这些代码，并进行了一些必要的调整，以开始进入第 2 章，您可以在上面的 GitHub 链接上访问该章。

从第 1 章构建的模型的一些调整也被纳入第 2 章的笔记本中，我们发现有必要增强建模系统的真实性。请在第 2 章笔记本中找到这些调整。

三、 识别性能指标并可视化结果

3.1 监控整个时间的餐馆拥挤程度

在经营一家餐馆时，管理层经常努力了解其场所的拥挤程度。传统上，他们唯一的评估方法是目视观察，以确定餐厅是否真的拥挤。然而，离散事件仿真 （DES） 为他们提供了一种更准确地量化和证明这种评估的方法。现在，我们将使用这种方法探索人群水平在开放日期间的变化情况。

下面的函数是代码之外的单独代码，用于模拟餐馆。它的作用是记录整个时间内餐馆内有多少顾客的统计数据，说明系统的动态

def monitor_customer(env):global timestampglobal customer_in_systemtimestamp = []customer_in_system = []while True:yield env.timeout(5) # for every 5 min of simulation run....timestamp.append(env.now) # ...record the timestamp....customer_in_system.append(customer - customer_served) # ....and record the number of customer in system

以前只包含代表模拟餐馆系统功能的主模型，现在正在与新流程并行运行，该流程也被馈送到

SimPyenv.process(customer_arrival(env,inter_arrival_time))monitor_customer(env)env.process()

将两个进程单独编码并并行运行的想法是因为该函数的目标是从独立运行的主仿真代码monitor_customer中提取数据。

因此，python 的主要模拟代码变为：

random.seed(100) #random seed to preserve same random number generatedenv = simpy.Environment() #create the essential simpy environmentstaff = simpy.Resource(env, capacity = 4) # number of staff
two_seater = simpy.Resource(env, capacity = 1) #two seater for one or couple customer
four_seater = simpy.Resource(env, capacity = 1) #four seater for three or four group of customercustomer = 0 #set the initial customer id starting from 0
customer_served = 0 #number of customer served during the start of simulation is zeroenv.process(customer_arrival(env, inter_arrival_time)) # the main 'customer arrival' model that represent the eatery system
env.process(monitor_customer(env)) # the monitoring function is being run in parallel with the main 'customer arrival' modelenv.run(until=60*8) # run the simulation for 8 hours
# print('\n')
print(f"TOTAL COMPLETE CUSTOMER:{customer_served}")
print(f"Customer in System during simulation end:{customer - customer_served}")plt.plot(timestamp, customer_in_system)# Add labels to the x and y axes
plt.xlabel('Simulation Clock (Min)')
plt.ylabel('Customer in System')print(f"Average customer in System: {np.mean(customer_in_system):.2f}")

现在执行它，看看结果！

TOTAL COMPLETE CUSTOMER:167 
Customer in System during simulation end:1 
Average customer in System: 5.85

在餐厅运营的模拟时间超过8小时，餐厅服务于167人，在任何给定时间平均有5.85名顾客在场。当我们检查上面的图表时，该图表描绘了系统中随时间推移的顾客数量，我们可以看到餐馆一次可容纳多达 12 名顾客。在一些地方，我们还可以看到餐馆内只有一位顾客，但自开业以来从未完全空无一人。

3.2 更改客容量

我们知道，从之前的模拟运行中，系统中的平均客户数量为一次 5.85 个人（如果在系统中再次运行笔记本，则可能会有所不同）。该结果是通过将输入参数（其中一个是员工人数）设置为 4 人获得的。让我们尝试设置不同的数字。假设我们减少了 3 名员工，因此现在只有 1 名员工。

要做到这一点，只需重新调用上面前面的主要 python 模拟代码，调整员工容量，然后重新运行它

staff = simpy.Resource(env, capacity = 1) #before was 4

TOTAL COMPLETE CUSTOMER:93
Customer in System during simulation end:63
Average customer in System: 35.34

结果
这家餐馆只有一名员工，难以应对大量涌入的顾客。客户的到来远远超过了员工为他们服务的能力。随着更多客户的到来，队列不断增长，导致系统中的客户数量超过可以容纳的情况。这比有四名工作人员的情况更具挑战性。在四名员工的情况下，有时客户数量会减少，从而产生更稳定的情况，但只有一名员工，客户数量会持续上升。

3.2 平均客户数量如何随员工人数的不同而变化

现在我们确定员工的数量肯定会影响系统内的客户数量。下一个问题是，考虑到客户到达模式，当前系统所需的理想员工人数是多少？为了确定这一点，我们将把员工输入参数从非常低到非常高，并观察系统内的平均客户数量如何变化。这可以使用“for 循环”函数来实现，如下所示。

random.seed(100)
number_of_staff = []
average_customer_in_system = []for staff_number in range(1,10):env = simpy.Environment() #create the essential simpy environmentstaff = simpy.Resource(env, capacity = staff_number) #stafftwo_seater = simpy.Resource(env, capacity = 1) #two seater for one or couple customerfour_seater = simpy.Resource(env, capacity = 1) #four seater for three or four group of customercustomer = 0 #set the initial customer id starting from 0customer_served = 0 #number of customer served during the start of simulation is zeroenv.process(customer_arrival(env, inter_arrival_time))env.process(monitor_customer(env))env.run(until=60*8) # run the simulation for 8 hoursnumber_of_staff.append(staff_number)average_customer_in_system.append(np.mean(customer_in_system))plt.plot(number_of_staff, average_customer_in_system )
plt.xlabel('Number of Staff')
plt.ylabel('Average Number of Customer in System')

结果
上述结果以折线图的形式呈现，说明了系统内的平均客户数量如何随着员工人数的变化而波动。当您检查图表时，您会注意到线条中出现了一个肘部，这表明该弯部出现的员工编号可能是最佳员工数量。在这种情况下，将员工从 1 设置为 2 足以减少系统内的客户数量。

3.3 更精确！

非常好！代码现在按预期运行。反映其发展，代码生成一个折线图，其中 x 轴表示时间戳，y 轴表示人数。然而，数据点的总数为96个。此计算公式为 （60 分钟 * 8 小时） 除以 5，其中 5 表示时间戳增量。为了得出平均值，对这 96 个数据点进行了平均。monitor_customer

但是，这种方法可能不是最准确的。为什么？考虑在 5 分钟时间戳增量内发生事件（如客户到达或离开）的场景。这些事件不会被函数记录，导致监控的准确性降低，因为某些时间间隔被有效地“跳过”了。为了提高准确性，我们可以将时间戳增量减少到 2 分钟，尽管代价是生成更多数据点。通过此调整，我们将（60 分钟 * 8 小时）除以 2 个数据点，从而更详细、更准确地表示客户活动。

# modification to monitor_customer functiondef monitor_customer(env):global timestampglobal customer_in_systemtimestamp = []customer_in_system = []while True:yield env.timeout(2) # the timestamp increment now is only 2 minutestimestamp.append(env.now)customer_in_system.append(customer - customer_served)

random.seed(100) #random seed to preserve same random number generatedenv = simpy.Environment() #create the essential simpy environmentstaff = simpy.Resource(env, capacity = 4) #staff
two_seater = simpy.Resource(env, capacity = 1) #two seater for one or couple customer
four_seater = simpy.Resource(env, capacity = 1) #four seater for three or four group of customercustomer = 0 #set the initial customer id starting from 0
customer_served = 0 #number of customer served during the start of simulation is zero
env.process(customer_arrival(env, inter_arrival_time))env.process(monitor_customer(env))
env.run(until=60*8) # run the simulation for 3 hours
# print('\n')
print(f"TOTAL COMPLETE CUSTOMER:{customer_served}")
print(f"Customer in System:{customer - customer_served}")plt.plot(timestamp, customer_in_system)
# Add labels to the x and y axes
plt.xlabel('Simulation Clock (Min)')
plt.ylabel('Customer in System')print(f"Average customer in System: {np.mean(customer_in_system)}")

TOTAL COMPLETE CUSTOMER:167
Customer in System:1
Average customer in System: 5.8

将监控时间戳更改为更精确（2 分钟）后，原来这家餐馆曾经有 13 人！以前 5 分钟的增量不会捕获此信息。

3.4 引入等待的人（而不是监控系统内整个客户的数量）

我们最初选择“系统中的客户数量”作为在仿真过程中评估系统的标准。然而，在与利益攸关方讨论后，出现了不同的观点。监测餐馆内的人数仍然缺乏清晰度。例如，如果餐馆里有 20 个人，而且他们都在积极用餐，那么可能根本没有问题。

这一认识促使我们修改了指标。我们现在将只关注目前在餐厅内等候的顾客。这种等待可能是为了订购或准备他们的订单。这些等待的客户会进入队列，这可作为可能需要注意的潜在问题的指标。利益攸关方认为，更小的队列将反映出一个更高效的系统。

# introducing variable that track number of people waiting inside the system.def till_activity(env, processing_time, customer, customer_type):global waiting_customer # variable called waiting_customer is created to record how many individuals are waitingwith staff.request() as till_request:waiting_customer += customer_type # the variable is added by customer_type to indicate that the set of customer consisting specific number of individuals are now waiting for the staff at tillyield till_requestwaiting_customer -= customer_type # after the customer get the staff to service at till, the variable is reduced by the customer_type, indicating that those individuals are waiting no moreyield env.timeout(processing_time["till_process"])order_type = random.randint(1,3)dining_in = random.choices([0,1], [0.2,0.8])[0]order_coffee = coffee_activity(env, processing_time, customer, customer_type, dining_in)order_pizza = pizza_activity(env, processing_time, customer, customer_type, dining_in)order_all = coffee_pizza_activity(env, processing_time, customer, customer_type, dining_in)if order_type == 1:env.process(order_coffee)elif order_type == 2:env.process(order_pizza)else: env.process(order_all)

我们需要调整和整合所有表示需要资源的过程的函数中的变量。逻辑与上面的代码完全相同。若要查看如何对所有剩余的 acitivity 过程代码执行此操作，可以查看 GitHub 链接上的笔记本文件。waiting_customer

更新 功能
由于我们没有监控系统中的客户，我们可以修改monitor_customer功能来监控等待的客户数量。但是，如果您仍想监视该变量，则可以创建新的另一个monitor_customer函数monitor_customer

def monitor_customer(env):global timestampglobal waiting_customer_arraytimestamp = []waiting_customer_array = []while True:yield env.timeout(2)timestamp.append(env.now)waiting_customer_array.append(waiting_customer)

random.seed(100) #random seed to preserve same random number generatedenv = simpy.Environment() #create the essential simpy environmentstaff = simpy.Resource(env, capacity = 1) #staff
two_seater = simpy.Resource(env, capacity = 1) #two seater for one or couple customer
four_seater = simpy.Resource(env, capacity = 1) #four seater for three or four group of customercustomer = 0 #set the initial customer id starting from 0
customer_served = 0 #number of customer served during the start of simulation is zero
waiting_customer = 0
env.process(customer_arrival(env, inter_arrival_time))env.process(monitor_customer(env))
env.run(until=60*8) # run the simulation for 3 hours
# print('\n')
print(f"TOTAL COMPLETE CUSTOMER:{customer_served}")
print(f"Customer in System:{customer - customer_served}")plt.plot(timestamp, waiting_customer_array)
# Add labels to the x and y axes
plt.xlabel('Simulation Clock (Min)')
plt.ylabel('Customer Waiting in System')print(f"Average customer waiting in System: {np.mean(waiting_customer_array)}")

导致

TOTAL COMPLETE CUSTOMER:93
Customer in System:63
Average customer waiting in System: 31.619246861924687

再次使用 for 循环函数尝试从 1 个员工到 10 个员工的不同员工数量输入，我们可以识别如下肘部：

结果：
有趣的是，将员工人数设置为两到三名将有效地消除等待客户的问题。这无疑对利益相关者有所帮助，使他们相信在当前的需求模式下，他们只需要不超过 2 名员工即可工作

3.5 失去机会和不满意的客户

干得好，我们几乎在第二章中就到了。现在我们想通过引入损失机会和不满意客户的概念来增强建模系统。那些是什么：

• 损失机会：潜在客户在目睹餐厅内有超过 5 人等候时决定不进入的情况。他们认为他们会等待很长时间，因为这会不那么方便
• 不满意的顾客：现在顾客打算在餐厅用餐时不会直接离开餐厅，而餐厅还没有空位。但是，他们只能等待这么长时间，建模为称为 的变量。如果他们等了一段时间后还有空位，他们会很不满意地离开这个地方。willingness_to_waitwillingness_to_wait

现在，让我们完成调整代码的工作！

# Integrating logic of LOSS OPPORTUNITY in customer_arrival codedef customer_arrival(env, inter_arrival_time):global customerglobal customer_servedglobal waiting_customerglobal loss_potential_customerloss_potential_customer = 0customer = 0 #represent the customer IDwhile True: #while the simulation is still in condition to be runyield env.timeout(inter_arrival_time)if waiting_customer <= 5:customer += 1 #customer ID addedcustomer_type = random.choices([1,2,3,4], [0.4,0.3,0.2,0.1])[0]# print(f"customer {customer} arrives at {env.now:7.4f}")next_process = till_activity(env, processing_time, customer, customer_type)env.process(next_process) #next process is integrated within this functionelse:loss_potential_customer += 1

# Integrating logic of DISSATISFIED CUSTOMER in dining_activity codedef dining_activity(env, processing_time, customer, customer_type):global customer_servedglobal waiting_customerglobal dissatisfied_customerwillingness_to_wait = random.uniform(15,30)if customer_type <= 2:with two_seater.request() as twoseater_request:waiting_customer += customer_typedecision = yield twoseater_request | env.timeout(willingness_to_wait) # the decision is whether there is available two seater or notif twoseater_request in decision:waiting_customer -= customer_typeyield env.timeout(processing_time["dining_in"]) # customer found two seater and dining incustomer_served += customer_type# print(f"Dining in complete at {env.now:7.4f} for customer {customer}")# print(f"Customer {customer} leaves at {env.now:7.4f}")else:# print(f"Customer {customer} leaves at {env.now:7.4f}") # after 10 seconds check, customer found no seat available, hence take awaycustomer_served += customer_typewaiting_customer -= customer_typedissatisfied_customer += customer_typeelse:with four_seater.request() as fourseater_request:waiting_customer += customer_typedecision = yield fourseater_request | env.timeout(willingness_to_wait) # same exact scenario for group of three or four looking for four seaterif fourseater_request in decision:waiting_customer -= customer_typeyield env.timeout(processing_time["dining_in"])# print(f"Dining in complete at {env.now:7.4f} for customer {customer}")# print(f"Customer {customer} leaves at {env.now:7.4f}")customer_served += customer_typeelse:# print(f"Customer {customer} leaves at {env.now:7.4f}")customer_served += customer_typewaiting_customer -= customer_typedissatisfied_customer += customer_type

让我们运行模拟

random.seed(100) #random seed to preserve same random number generatedenv = simpy.Environment() #create the essential simpy environmentstaff = simpy.Resource(env, capacity = 2) #staff
two_seater = simpy.Resource(env, capacity = 1) #two seater for one or couple customer
four_seater = simpy.Resource(env, capacity = 1) #four seater for three or four group of customercustomer = 0 #set the initial customer id starting from 0
customer_served = 0 # number of customer served during the start of simulation is zero
waiting_customer = 0
dissatisfied_customer = 0env.process(customer_arrival(env, inter_arrival_time))
env.process(monitor_customer(env))env.run(until=60*8) # run the simulation for 3 hoursplt.plot(timestamp, waiting_customer_array)
# Add labels to the x and y axes
plt.xlabel('Simulation Clock (Min)')
plt.ylabel('Customer Waiting in System')print(f"Average customer waiting in System: {np.mean(waiting_customer_array):.2f}")
print(f"Loss Potential Customer Count (Loss Opportunity): {loss_potential_customer}")
print(f"Dissatisfied Customer Count: {dissatisfied_customer}")

Average customer waiting in System: 2.11
Loss Potential Customer Count (Loss Opportunity): 4
Dissatisfied Customer Count: 10

新座位到货！！
太好了，新座位是从一周前的订单到货的，现在可以使用了。将它们添加为输入参数。现在结果如何。

staff = simpy.Resource(env, capacity = 2) #staff
two_seater = simpy.Resource(env, capacity = 5) #two seater for one or couple customer
four_seater = simpy.Resource(env, capacity = 2) #four seater for three or four group of customer

Average customer waiting in System: 0.87
Loss Potential Customer Count (Loss Opportunity): 0
Dissatisfied Customer Count: 0

结果：
Horray，不仅增加了座位，大大减少了平均客户在系统中的等待时间，而且有效地消除了潜在客户数量流失和客户不满意的问题。

现在，我们很幸运，新座位的到来已经计划了很长时间。如果不是这样，如果利益相关者反而问你什么是有效的座位增加，这样餐馆就不会花太多钱买新座位怎么办？（PSST，你可以再做一次“肘部”分析）

四、资源利用率

说到花钱买新座椅，还不如综合评估一下。每当我们有资源资产来支持餐馆运营时，我们还想知道该特定资源的使用频率。直观地说，如果特定资源的使用率很高，我们可能需要添加新的资产，并且我们知道如果利用率很低，则不需要它。在本节中，我们将再次更新代码，以便它能够监控座椅的使用率。

# Integrate the variable that track seaters utilization in dining_activity function codedef dining_activity(env, processing_time, customer, customer_type):global customer_servedglobal waiting_customerglobal twoseater_utilglobal fourseater_utilwillingness_to_wait = random.uniform(15,30)if customer_type <= 2:with two_seater.request() as twoseater_request:waiting_customer += customer_typedecision = yield twoseater_request | env.timeout(willingness_to_wait) # the decision is whether there is available two seater or notif twoseater_request in decision:twoseater_util += 1waiting_customer -= customer_typeyield env.timeout(processing_time["dining_in"]) # customer found two seater and dining incustomer_served += customer_typetwoseater_util -= 1# print(f"Dining in complete at {env.now:7.4f} for customer {customer}")# print(f"Customer {customer} leaves at {env.now:7.4f}")else:# print(f"Customer {customer} leaves at {env.now:7.4f}") # after 10 seconds check, customer found no seat available, hence take awaycustomer_served += customer_typewaiting_customer -= customer_typeelse:with four_seater.request() as fourseater_request:waiting_customer += customer_typedecision = yield fourseater_request | env.timeout(willingness_to_wait) # same exact scenario for group of three or four looking for four seaterif fourseater_request in decision:fourseater_util += 1waiting_customer -= customer_typeyield env.timeout(processing_time["dining_in"])# print(f"Dining in complete at {env.now:7.4f} for customer {customer}")# print(f"Customer {customer} leaves at {env.now:7.4f}")customer_served += customer_typefourseater_util -= 1else:# print(f"Customer {customer} leaves at {env.now:7.4f}")customer_served += customer_typewaiting_customer -= customer_type
# create monitor_utilization code to track the utilization over time, same logic as monitor_customerdef monitor_utilization(env):global timestampglobal twoseater_util_arrayglobal fourseater_util_arraytimestamp = []twoseater_util_array = []fourseater_util_array = []while True:yield env.timeout(2)timestamp.append(env.now)twoseater_util_array.append(twoseater_util)fourseater_util_array.append(fourseater_util)

运行主模型（现在它由三个并行进程组成！

random.seed(100) #random seed to preserve same random number generatedenv = simpy.Environment() #create the essential simpy environmentset_twoseater = 3
set_fourseater = 1staff = simpy.Resource(env, capacity = 2) #staff
two_seater = simpy.Resource(env, capacity = set_twoseater) #two seater for one or couple customer
four_seater = simpy.Resource(env, capacity = set_fourseater) #four seater for three or four group of customercustomer = 0 #set the initial customer id starting from 0
customer_served = 0 #number of customer served during the start of simulation is zero
waiting_customer = 0
twoseater_util = 0
fourseater_util = 0env.process(customer_arrival(env, inter_arrival_time))
env.process(monitor_customer(env))
env.process(monitor_utilization(env))env.run(until=60*8) # run the simulation for 3 hoursprint(f"Average customer waiting in System: {np.mean(waiting_customer_array):.3f}")
print(f"Loss Potential Customer Count: {np.mean(loss_potential_customer)}")
print(f"Average usage of two seater: {np.mean(twoseater_util_array):.3f}, and the overall utilization is {np.mean(twoseater_util_array)/set_twoseater:.0%}  ")
print(f"Average usage of four seater: {np.mean(fourseater_util_array):.3f}, and the overall utilization is {np.mean(fourseater_util_array)/set_fourseater:.0%}  ")

结果：

Average customer waiting in System: 1.155
Loss Potential Customer Count: 4.0
Average usage of two seater: 0.929, and the overall utilization is 31%  
Average usage of four seater: 0.552, and the overall utilization is 55%  

4.1 设置不同数量的席位将如何影响其整体集体利用率

为了解决这个问题，我们可以以双座资源为例，测试不同的座位配置如何导致不同的利用率。现在使用 for 循环函数逻辑再次运行它，现在双座车的数量是切换，我们得到以下结果：

4.2 结果

        基于这一结果，双座桌子的使用率在增加时会逐渐明显下降。利益相关者必须足够明智地决定他们需要多少席位。如果它仍然很高，那么人们需要等待座位的可能性一定很高，因为它不可用。如果它太低，则表明座椅太多，随着时间的推移并没有真正使用。

五、在队列和资源利用率之间

等待某些资源而产生的每个队列确实与资源本身的利用率相关。利用率越高，在资源容量过大时创建队列的几率就越高。相反，需要资源的实体越少，资源的使用率就越低。

作为系统所有者，这取决于我们是否要将队列或利用率视为评估标准。从客户/客户的角度来看，队列将表现得更好，因为它关系到他们的体验。根除排队将保证及时交货，提高满意度。另一方面，为了追求运营效率，关注利用率可能很重要。为了压下运营支出，我们确实不想把钱花在那些没有得到适当利用的东西上。

你怎么看？如果你是咖啡和披萨店的老板，你会最关心排队，还是最关心使用率？