Queue worker supervision in Laravel - Performance & Optimization

Performance: Queue worker supervision

MEDIUM IMPACT

This affects backend job processing speed and reliability, indirectly impacting frontend user experience by reducing delays and errors.

Ensuring queue workers keep running and restart automatically on failure

Laravel

Use Laravel Horizon or Supervisor to monitor and auto-restart queue workers:
# Supervisor config example
[program:laravel-worker]
command=php /path/to/artisan queue:work --sleep=3 --tries=3
process_name=%(program_name)s_%(process_num)02d
numprocs=3
autostart=true
autorestart=true
stderr_logfile=/var/log/worker.err.log
stdout_logfile=/var/log/worker.out.log

Automatically restarts workers on failure, keeps multiple workers running for parallel job processing.

📈 Performance GainReduces job backlog and downtime, improving backend throughput and frontend responsiveness.

Ensuring queue workers keep running and restart automatically on failure

Laravel

php artisan queue:work --once
# Manually restarting workers after failure or crash

Workers stop after processing one job and require manual restart, causing delays and job backlog.

📉 Performance CostCauses job processing delays, increasing backend response time and user wait time.

Performance Comparison

Pattern	Worker Uptime	Job Processing Delay	Backend Throughput	Verdict
Manual restart after failure	Low (stops after one job)	High (delays until manual restart)	Low (jobs pile up)	[X] Bad
Supervisor or Horizon auto-restart	High (continuous running)	Low (immediate job processing)	High (parallel workers)	[OK] Good

Rendering Pipeline

Queue worker supervision does not directly affect browser rendering but impacts backend job processing that supports frontend data availability and responsiveness.

→Backend Job Processing

→API Response Time

⚠️ BottleneckWorker downtime or crashes causing job backlog and delayed responses

Core Web Vital Affected

INP

This affects backend job processing speed and reliability, indirectly impacting frontend user experience by reducing delays and errors.

Optimization Tips

1Always use a process supervisor like Supervisor or Laravel Horizon to keep queue workers running.

2Avoid running queue workers with --once without automatic restart to prevent job backlog.

3Monitor worker health and job queues regularly to maintain backend responsiveness.

Performance Quiz - 3 Questions

What is the main performance benefit of supervising Laravel queue workers with Supervisor or Horizon?

A Reduces frontend rendering time by optimizing CSS

B Automatically restarts workers to prevent downtime and job backlog

C Improves database query speed by caching results

D Minimizes JavaScript bundle size for faster loading

DevTools: Network and Console

How to check: Use browser DevTools Network panel to monitor API response times; check backend logs or Horizon dashboard for worker status.

What to look for: Look for consistent fast API responses and no backend job backlog or worker crash logs.

Practice

1. What is the main purpose of using Supervisor with Laravel queue workers?

easy

A. To automatically restart queue workers if they stop unexpectedly

B. To speed up the execution of queue jobs

C. To log all queue jobs to a database

D. To convert queue jobs into synchronous tasks

Solution

1. Step 1: Understand Supervisor's role

   Supervisor monitors processes and restarts them if they stop.

2. Step 2: Apply this to Laravel queue workers

   Laravel queue workers run background jobs; Supervisor ensures they keep running.

3. Final Answer:

   To automatically restart queue workers if they stop unexpectedly -> Option A

4. Quick Check:

   Supervisor restarts workers automatically [OK]

Hint: Supervisor restarts stopped workers automatically [OK]

Common Mistakes:

• Thinking Supervisor speeds up job execution
• Confusing logging with supervision
• Believing Supervisor makes jobs synchronous

2. Which of the following is the correct Supervisor configuration directive to specify the command to run a Laravel queue worker?

easy

A. run=php artisan queue:work

B. command=php artisan queue:work

C. execute=php artisan queue:work

D. start=php artisan queue:work

Solution

1. Step 1: Recall Supervisor config syntax

   Supervisor uses 'command=' to specify the process command.

2. Step 2: Match with Laravel queue worker command

   Laravel queue worker runs with 'php artisan queue:work'.

3. Final Answer:

   command=php artisan queue:work -> Option B

4. Quick Check:

   Supervisor uses 'command=' for process commands [OK]

Hint: Supervisor config uses 'command=' for commands [OK]

Common Mistakes:

• Using 'run=' instead of 'command='
• Confusing 'execute=' or 'start=' as valid directives
• Omitting the full artisan command

3. Given this Supervisor config snippet:

[program:laravel-worker]
command=php /var/www/artisan queue:work --sleep=3 --tries=3
numprocs=1
autostart=true
autorestart=true
user=www-data

What happens if the Laravel queue worker process crashes?

medium

A. Supervisor will restart the worker automatically

B. The worker will remain stopped until manually restarted

C. Supervisor will log the crash but not restart the worker

D. The worker will restart only if autostart is false

Solution

1. Step 1: Check 'autorestart' setting

   autorestart=true means Supervisor restarts crashed processes automatically.

2. Step 2: Understand autostart role

   autostart=true means the worker starts on Supervisor start, but restart depends on autorestart.

3. Final Answer:

   Supervisor will restart the worker automatically -> Option A

4. Quick Check:

   autorestart=true means auto restart on crash [OK]

Hint: autorestart=true means auto restart on crash [OK]

Common Mistakes:

• Confusing autostart with autorestart
• Assuming manual restart is needed
• Thinking Supervisor only logs crashes

4. You configured Supervisor to run Laravel queue workers but notice workers are not restarting after failure. Which of these is the most likely cause?

medium

A. The 'numprocs' option is set to 0

B. The 'command' option is missing the '--tries' flag

C. The 'user' option is set to 'root'

D. The 'autorestart' option is set to false or missing

Solution

1. Step 1: Identify why workers don't restart

   Workers won't restart if 'autorestart' is false or missing.

2. Step 2: Check other options' impact

   'numprocs=0' disables processes, 'user=root' is allowed but not recommended, '--tries' controls job retries, not restarts.

3. Final Answer:

   The 'autorestart' option is set to false or missing -> Option D

4. Quick Check:

   autorestart=false stops auto restart [OK]

Hint: Check 'autorestart' to fix no restart issue [OK]

Common Mistakes:

• Confusing job retry with process restart
• Thinking 'user=root' causes restart failure
• Assuming '--tries' affects Supervisor restart

5. You want to run multiple Laravel queue workers supervised by Supervisor to handle high job volume. Which configuration change is best to achieve this?

hard

A. Set 'numprocs' to 1 and increase '--sleep' time in the command

B. Create multiple Supervisor config files each with one worker and same program name

C. Set 'numprocs' to the number of workers needed and use '%(program_name)s_%(process_num)s' in 'process_name'

D. Use 'autostart=false' and manually start each worker process

Solution

1. Step 1: Understand running multiple workers

   Supervisor can run multiple processes with 'numprocs' and unique names.

2. Step 2: Use 'process_name' for unique worker IDs

   Using '%(program_name)s_%(process_num)s' creates unique names for each worker.

3. Final Answer:

   Set 'numprocs' to the number of workers needed and use '%(program_name)s_%(process_num)s' in 'process_name' -> Option C

4. Quick Check:

   Multiple workers = numprocs + unique process_name [OK]

Hint: Use numprocs and unique process_name for multiple workers [OK]

Common Mistakes:

• Duplicating config files with same program name
• Increasing sleep time reduces throughput
• Disabling autostart prevents automatic worker start