Notes on Laravel queue

Notes on Laravel queue

Because I advocate simplicity, I hate all so-called "heavyweight" frameworks, such as "Laravel". Sometimes this hatred is even paranoid, if my resume says "proficient Laravel", I will not hesitate to PASS the candidate. But now I admit that I like Laravel A Little Bit. Although the performance is still a shortcoming that cannot be avoided, how many other websites can touch its performance bottleneck? Its rich components actually save a lot of time for developers, such as the queue mentioned in this article.

Calling the queue function in Laravel is very simple. For details, refer to the official documentation:

<?php\Queue::pushOn('mail', new \App\Commands\Mail($data));?>

The queue contains multiple drivers, such as sync, database, redis, and beanstalk. Sync seems strange at first glance, but in fact it is extremely convenient in the development and testing phase. In addition, database, redis and other solutions are more like a simulation, therefore, beanstalk is currently the most appropriate choice. Of course, beanstalk is significantly inferior in terms of functions compared with queues such as nsq. However, beanstalk is easy to use.

The Laravel queue consumer has two startup modes: queue: listen and queue: work. I suggest you forget the first one. I don't even understand why it exists, it is not only inefficient, but may cause some inexplicable problems. For details, refer to the alarm triggered by a Laravel queue.

Once the queue: work mode is selected, you must note that improper setting of the default values may cause the following problems:

• Delay: If a task fails, the task will be re-executed after several seconds. The default value of this time is "0", that is, no delay. Generally, this is not a good choice. For example, if the network is unstable, retry immediately without delay. We recommend that you set it to "1 」.
• Sleep: If there is no valid task, the system pause for several seconds and then re-check. The default value for this time is "3 」. However, if a new task suddenly comes, it may be paused for 3 seconds before the response starts. In many cases, this is a little too long. We recommend that you set it to "1 」.
• Tries: If a task fails, try again several times. The default value of this number is "0", but it does not mean not to retry, but to retry continuously. In some cases, if the problem is serious, continuous Retry is equivalent to an endless loop. We recommend that you set it to "3 」.

In the production environment, it is easy to ignore whether the queue is congested. Taking beanstalk as an example, it provides the stats command, allowing us to conveniently query the queue status:

shell> echo -e "stats\r" | nc <IP> <PORT>

However, this command has a lot of output. How can we determine what is related to congestion? The simplest way is to manually create congestion faults and compare the results before and after the comparison to find differences. The results of my test are as follows:

• Current-jobs-urgent
• Current-jobs-ready
• Current-jobs-reserved
• Current-jobs-delayed
• Current-jobs-buried

We can easily monitor whether beanstalk is congested through zabbix:

Beanstalk Jobs

We can set the corresponding alarm trigger. For example, if we set more than 10 congested tasks, we will not go into details about the specific configuration methods, you can refer to the description of UserParameters on the official website.

This article permanently updates the link address: