Queuing Model for Photoshoot Workflow

From One to Many: The M/M/s Model

The M/M/s model is the natural extension of the M/M/1 model for systems with multiple, identical servers working in parallel. The notation, following the Kendall convention you're familiar with, stands for:

• M: Markovian (Poisson) arrival process.
• M: Markovian (exponential) service time distribution for each server.
• s: The number of identical, parallel servers.

The key operational difference is that arriving "customers"—in our case, photoshoot looks—join a single queue and are served by the first available server. This setup is fundamentally more efficient than having separate queues for each server, a phenomenon you know from operations as the benefit of pooling.

A crucial adjustment from the M/M/1 model is the stability condition. For the queue to remain finite, the total service capacity of the system must exceed the arrival rate.

$\lambda <s\mu$

Where:

• $\lambda$ is the average arrival rate.
• $\mu$ is the average service rate per server.
• $s$ is the number of servers.

This implies that as long as the total potential work output of all servers combined is greater than the incoming workload, the system can eventually catch up.

The Power of Pooling and Economies of Scale

Before we dive into the formulas, it's important to grasp the core principle at play. In queueing systems, delays are highly sensitive to both utilization and variability. As you saw in the previous lesson, wait times increase non-linearly as utilization approaches 100%.

Adding a server does more than just add capacity; it creates a more robust and flexible system. Because servers are pooled, a random spike in service time for one customer is less likely to cause a significant backlog, as another server can handle the next arrival. This leads to what is known as "economies ofscale" in queueing.

The Mathematics of the M/M/s Model

The formulas for the M/M/s model are more complex than for the M/M/1, primarily because we must account for the probability of different numbers of servers being busy. The most critical, and most complex, calculation is for $P_0$, the probability that the system is completely empty. All other performance measures depend on it.

The key performance measures we will calculate are:

• Utilization per server ($\rho$): $\rho =\frac{\lambda }{s\mu }$
• Probability of an empty system ($P_0$): Given by the complex formula you just reviewed.
• Probability of any delay ($P_D$): The probability that an arriving customer will have to wait because all servers are busy. This is also known as the Erlang C formula.
• Average time in queue ($W_q$): The average time a customer spends waiting before service begins.

Application: The Photoshoot with an Assistant

Let's now apply this model to evaluate the benefit of adding an assistant to the boudoir photoshoot. We assume the assistant is also a competent photographer, effectively creating a two-server ($s=2$) system.

System Parameters (from last lesson):

• Arrival Rate ($\lambda$): 4 looks per hour.
• Service Rate per Server ($\mu$): 5 looks per hour.

Scenario 1: M/M/1 Model (Single Photographer) - Recap

As a baseline, let's recall the results from our previous analysis with a single photographer ($s=1$):

• Utilization ($\rho$): $\frac{4}{5}=0.8$ (or 80%)
• Average Wait in Queue ($W_q$): 48 minutes

Scenario 2: M/M/2 Model (Photographer + Assistant)

Now, let's analyze the system with two servers ($s=2$).

1. Check Stability: The total service rate is $s\mu =2\times 5=10$ looks per hour. Since $\lambda =4<10$, the system is stable.
2. Calculate Utilization: The utilization per server is now $\rho =\frac{\lambda }{s\mu }=\frac{4}{10}=0.4$ (or 40%). This is a dramatic reduction.

The next steps involve calculating the performance metrics using the M/M/s formulas. The calculation of $P_0$ can be tedious, but the following video provides an excellent walkthrough for a two-server case, which will give you a concrete feel for the process.

Let's perform the calculations for our photoshoot scenario:

• Calculate $P_0$: Using the formula from the reading, with $s=2$ and $\lambda /\mu =4/5=0.8$, we get:
  $P_0={\left[{\sum }_{n=0}^1\frac{(0.8{)}^n}{n!}+\frac{(0.8{)}^2}{2!}\frac{1}{1-0.4}\right]}^{-1}={\left[(1+0.8)+\frac{0.64}{2}\left(\frac{1}{0.6}\right)\right]}^{-1}\approx 0.4286$
  There is about a 43% chance the entire system (both photographer and assistant) is idle.

• Calculate $P_D$ (Probability of Delay): This is the probability that an arriving look finds both photographers busy.
  $P_D=\frac{1}{1-\rho }\frac{(\lambda /\mu {)}^s}{s!}{P}_0=\frac{1}{1-0.4}\frac{(0.8{)}^2}{2!}(0.4286)\approx 0.2286$
  There is about a 23% chance that a new look will have to wait at all. Compare this to the M/M/1 case, where the probability of waiting was simply the utilization, $\rho =80\%$.

• Calculate $W_q$ (Average Wait in Queue):
  $W_q=\frac{P_D}{s\mu -\lambda }=\frac{0.2286}{10-4}=0.0381\text{ hours}$
  Converting to minutes: $0.0381\times 60\approx \text{2.3 minutes}$.

Benefit Evaluation:
The benefit of adding an assistant is staggering.

• Wait Time (M/M/1): 48 minutes
• Wait Time (M/M/2): 2.3 minutes

By adding an assistant, the average wait time for a look is reduced by over 95%. This isn't just because capacity doubled; it's because the per-server utilization dropped from a high-congestion 80% to a low-congestion 40%, moving the system far away from the steep "elbow" of the waiting time curve.

Economic Justification

As an optimizer, you know that reducing wait time is only part of the story. The ultimate decision rests on a cost-benefit analysis. Is the cost of the assistant justified by the savings from reduced waiting?

Let's create a simple cost model for the photoshoot:

• Waiting Cost ($C_w$): The cost of a styled look waiting to be shot. This could represent model fatigue, creative momentum loss, or simply the hourly rate of the model. Let's assume this is $100 per hour of waiting.
• Service Cost ($C_s$): The hourly cost of the servers. Let's say the main photographer costs $150/hr and the assistant costs $50/hr.

Now, let's calculate the total cost per hour for each scenario. The total hourly waiting cost is the arrival rate multiplied by the average wait time, times the cost per hour ($\lambda W_q{C}_w$).

• Total Cost (M/M/1):

  • Waiting Cost = $4\text{ looks/hr}\times 0.8\text{ hr/look}\times \$100/\text{hr}=\$320/\text{hr}$
  • Service Cost = $1\times \$150=\$150/\text{hr}$
  • Total System Cost = $470 per hour

• Total Cost (M/M/2):

  • Waiting Cost = $4\text{ looks/hr}\times 0.0381\text{ hr/look}\times \$100/\text{hr}\approx \$15.24/\text{hr}$
  • Service Cost = $\$150+\$50=\$200/\text{hr}$
  • Total System Cost \approx $215.24 per hour

The analysis is unequivocal. Even though the hourly service cost increases by $50, the total system cost is more than halved because the waiting costs are almost entirely eliminated. The benefit of adding the assistant is not just a smoother workflow; it is a massive economic gain.

Conclusion

In this lesson, we have extended our queueing analysis to multi-server systems using the M/M/s model. By applying it to your photoshoot workflow, you've gone beyond simply identifying a bottleneck to precisely quantifying the operational and economic benefits of adding capacity.

Key Takeaways:

• The M/M/s model is used for systems with a single queue and multiple identical, parallel servers.
• The stability of an M/M/s system requires that the total service capacity exceeds the arrival rate ($\lambda <s\mu$).
• Adding servers provides a non-linear reduction in waiting time due to the effects of resource pooling and lower per-server utilization.
• The M/M/s model allows for a quantitative cost-benefit analysis, balancing the increased cost of servers against the reduced cost of waiting to find an optimal system configuration.

In our next lesson, we will step back and critically examine the "M" assumptions (Poisson arrivals, exponential service times) that underpin both the M/M/1 and M/M/s models. We will discuss the implications of these assumptions and what happens when real-world systems deviate from this idealized, highly variable behavior.