What is the difference between queue:work –daemon and queue:listen

by

Edit updated 2017-04-07:

There are now three ways to run your queue:

  • queue:work – this is the new “daemon” process (the flag is no longer required). The framework will fire up “once” – and then keep looping through the jobs. This will continue indefinitely. It uses less memory/cpu than queue:listen because the framework stays up the entire time. You must also remember to use queue:restart to force the queue to update any code changes you push during patching.

  • queue:work --once – this will fire up the framework, process one job, then shutdown. Useful for testing during development etc.

  • queue:listen – this will fire the framework up on every cycle, process one job, then fully shutdown, and then fire the framework up again etc and loop indefinitely. This means all memory/processes are released after each job is processed. If you have memory leaks with queue:work – give this a try.

The --daemon flag no longer has an effect on these commands.

Original answer:

There are two different issues listed.

There is artisan queue:work and artisan queue:listen

  • queue:work will simply pop off the next job in the queue, and process only that one job. This is a ‘one off’ command that will return to the command prompt once the one queue command is processed.
  • queue:listen will listen to the queue, and continue to process any queue commands it receives. This will continue running indefinitely until you stop it.

In Laravel >=4.2 there was a --daemon command added. The way it works is simply keeps running the queues directly, rather than rebooting the entire framework after every queue is processed. This is an optional command that significantly reduces the memory and cpu requirements of your queue.

The important point with the --daemon command is that when you upgrade your application, you need to specifically restart your queue with queue:restart, otherwise you could potentially get all sorts of strange errors as your queue would still have the old code in memory.

So to answer your question “Which command should I use for running my daemons?” – the answer is almost always queue:work --daemon

More Related Contents:

  1. Laravel – Route::resource vs Route::controller
  2. Laravel Redirect Back with() Message
  3. Rollback one specific migration in Laravel
  4. Can Anyone Explain Laravel 5.2 Multi Auth with Example
  5. How to protect image from public view in Laravel 5?
  6. Eloquent Collection: Counting and Detect Empty
  7. Laravel Check If Related Model Exists
  8. Persisting sessions across subdomains in Laravel 5
  9. How do I catch exceptions / missing pages in Laravel 5?
  10. How to change / Custom password field name for Laravel 4 and Laravel 5 user authentication [duplicate]
  11. How to Get the Current URL Inside @if Statement (Blade) in Laravel 4?
  12. laravel with() method versus load() method
  13. Laravel – Forbidden You don’t have permission to access / on this server
  14. Undefined variable: errors in Laravel
  15. Laravel Eloquent “WHERE NOT IN”
  16. Laravel 5.4^ – How to customize notification email layout?
  17. How to use paginate() with a having() clause when column does not exist in table
  18. Laravel 5 – Manual pagination
  19. What is difference between use env(‘APP_ENV’), config(‘app.env’) or App::environment() to get app environment?
  20. 404 Not Found, but route exist in Laravel 5.4
  21. Eloquent push() and save() difference
  22. Laravel save / update many to many relationship
  23. First Or Create
  24. I’m getting error “Class ‘Predis\Client’ not found” in Laravel 5.2
  25. Has many through many-to-many
  26. Laravel: Change base URL?
  27. Laravel 4 : Route to localhost/controller/action
  28. Modify existing Authorization module (email to username)
  29. Clone an Eloquent object including all relationships?
  30. Laravel: how to set date format on model attribute casting?

Leave a Comment