In the last lesson, I showed you the ShouldQueue implementation on the notification email notification. Now let's explore other classes that can use queues in Laravel to further improve your application's performance.
What are Other Queueable Classes?
What other classes can have ShouldQueue in Laravel? There are four results if we go to the Laravel documentation and search for ShouldQueue. One of them is just about queues in general. But three more classes can be queueable. We saw notifications in a previous lesson. Also, event listeners and mails.
Let's try the other two approaches - events with listeners and emails - to implement the same functionality we did previously.
Events and Listeners Class
Laravel fires a Registered event when a user registers and is created. This is a perfect opportunity to implement...
Hi everyone, my Fun Retirement Project runs on a linux server. I just want to understand how the worker for the queue gets startet. There is an advice to implement "Supervisor" to get the queue jop startet anyway (even after restart, crash etc). But is there no possilbe way to get the application run the worker maybe after an event ? I understood that "Supervisor" starts a defined .conf file where one of the line is "command=php /var/www/app_name/artisan queue:work database --sleep=3 --tries=3 --max-time=3600" which starts the worker do to the Jobs. Or am I on a wrong way ?
The limitation with what you're proposing is that, when handling requests through an http server, PHP is not a daemon (server) like, say, Node. It's a request runner. It's stateless and short lived and is not meant to stick around after it has serviced the request.
The way it works under the hood is, each time a request comes in a PHP worker (not to be confused with a Laravel worker) is pulled out of a finite pool. Then, your app (plus the framework and any other composer packages you're using) is loaded then bootstrapped by it. It handles the request, returns a response and then is completely reset and returned to the pool. It is essential that it doesn't stick around doing or waiting for other tasks after it has handled the request. That could end up blocking all your workers and you'd risk DoSing your own server by making it unresponsive to new requests.
So it's best to go the supervisor route, which actually does turn the Laravel worker it manages into a daemon, listening for jobs put on the queue and executing them, but does it isolated from the PHP workers servicing requests.