Laravel Queues Overview 0:00Laravel ships with the ability to push time-consuming tasks into a queue. Each queue job gets executed asynchronously by a worker away from our main application. An queue worker is a process that looks through the stack of jobs in the queue and executes them one by one. We can configure our application to run one or more queue workers, allowing us to control the number of jobs our application can process at any one time. In Laravel, queues are configured within our application's code through the config queue configuration file. Here we're able to configure different queue connections and the queues themselves. By default, Laravel creates a queue configuration file with several connections already configured Connections vs Queues 0:33Here we're able to configure different queue connections and the queues themselves. By default, Laravel creates a queue configuration file with several connections already configured for us. Here we can see sync, which will run our queues synchronously against our code, database, Beanstalk, SQS, and Redis. When I first started working with queue jobs myself, I was confused by the difference between connections and queues, but actually it's pretty simple. Think of the connection, which is Redis in this case, similar to how we can configure MySQL, Postgres, or SQLite for our database. For our queue connection, we may want to use Redis, our database, or Amazon SQS.MySQL, Postgres, or SQLite for our database. For our queue connection, we may want to use Redis, our database, or Amazon SQS. There are a bunch of options available to us. The queue configuration is the pile or stack that we want to add jobs to within this connection. If we put it all together, we may want to push our jobs to the Redis connection, and then we could have two queues, one for notifications and one for queue uploads. This way we can configure our queue workers to process the uploads queue faster by adding more workers, but letting our notifications work slower as they may not be as critical to our application. Some queue drivers will require additional packages to be installed, Redis is one of Creating Forge Queue Worker 1:45to our application. Some queue drivers will require additional packages to be installed, Redis is one of them. Let's see what we can do to install that. To use the Redis connection, we'll need to require predis predis in our application. This will add the predis dependency to our composer.json and lock files, and we'll now be able to use Redis as our queue connection. Now let's switch back to the Forge dashboard and see how we can configure our queue workers. On our site, we will go down to the queue panel and we can create a new worker. So here the connection is the connection that we want to use, which could be Redis, andOn our site, we will go down to the queue panel and we can create a new worker. So here the connection is the connection that we want to use, which could be Redis, and the queue could be notifications. Forge already provides us with some sane defaults for the rest of the queue options. Queue jobs may run for 60 seconds. We can configure how many seconds to wait before processing new jobs, the number of times a job should be tried, and if we scroll down further, which version of PHP the worker should run with. Of course, there are many more options here, and if you're unsure what these settings relate to, you should read the Laravel documentation. Supervisor Worker Management 2:49Of course, there are many more options here, and if you're unsure what these settings relate to, you should read the Laravel documentation. The docs go into far more detail about how these settings can be configured. Aside from the connection and queue fields, we're going to leave everything else as the Forge defaults to create this worker. Let's create that now. So while this installs, let's explain how this works. Forge is going to create a supervisor configuration file, much like it does for the daemons, but instead of us having to create a daemon and supply all of these potential parameters, Forge is actually going to just do that for us.instead of us having to create a daemon and supply all of these potential parameters, Forge is actually going to just do that for us. With a queue worker created, our application can now start to process any jobs that we push to the queue. Of course, we can manage the queue workers too. We can restart it, and we can also view the output to ensure that things are running smoothly. In this case, we have no jobs on the queue, so there is no content available. We're also able to see the worker status of all of our supervisor jobs here. We can see that we have an existing daemon and also a worker.We can see that we have an existing daemon and also a worker.
