Laravel Queue Worker监听AWS SQS请求量过高问题咨询

Great question—this is such a common pitfall when using Laravel with SQS, especially when your queues are mostly quiet (like your case with only hundreds of actual tasks this month). Let’s break this down clearly:

1. Do Worker Polls Count Toward SQS Request Limits? #

First off: yes, every time your Laravel worker checks the queue for tasks, that counts as an SQS API request (specifically a ReceiveMessage call).

By default, Laravel’s SQS driver uses short polling. That means if your queue is empty, each worker will keep sending a ReceiveMessage request every few seconds (default is every 1 second if you don’t set a sleep value). With 2 workers running 24/7, that’s 2 * 60 * 60 * 24 = 172,800 requests per day—easily adding up to 5+ million requests a month, which explains why you’re hitting 887k already despite only hundreds of actual tasks.

2. Can You Adjust Polling Intervals? #

Absolutely—here are the best ways to cut down on unnecessary requests:

Enable Long Polling (The Best Fix) #

Long polling is designed exactly for this scenario. Instead of your worker repeatedly asking SQS “any tasks?” every second, SQS holds the connection open for a set period (up to 20 seconds) and only responds when a task arrives or the timeout hits. This drastically reduces empty poll requests.

To set this up in Laravel:

• Open config/queue.php
• Find your SQS connection configuration, and add the wait_time_seconds parameter (set to 20, the maximum allowed):

  'sqs' => [
      'driver' => 'sqs',
      'key' => env('AWS_ACCESS_KEY_ID'),
      'secret' => env('AWS_SECRET_ACCESS_KEY'),
      'prefix' => env('SQS_PREFIX', 'https://sqs.us-east-1.amazonaws.com/your-account-id'),
      'queue' => env('SQS_QUEUE', 'default'),
      'suffix' => env('SQS_SUFFIX'),
      'region' => env('AWS_DEFAULT_REGION', 'us-east-1'),
      'wait_time_seconds' => 20, // Add this line
  ],
  

This tells Laravel to use long polling for that SQS connection. You don’t need to change anything in the AWS console (though enabling long polling there too won’t hurt—it just ensures consistency).

Adjust Worker Sleep Time (For Short Polling) #

If you stick with short polling (not recommended over long polling), you can make workers wait longer between empty polls using the --sleep flag when starting your worker:

php artisan queue:work sqs --sleep=10

This makes the worker wait 10 seconds before checking the queue again if no tasks were found. While this reduces requests, it’s less efficient than long polling because you’ll still have delays in processing new tasks (up to 10 seconds instead of instant with long polling).

Dynamically Scale Worker Count #

For even more optimization, consider using a process manager like Supervisor to scale the number of workers based on queue length. For example:

• Keep 1 worker running when the queue is empty
• Spin up additional workers only when there are pending tasks
  This way you avoid having multiple workers polling an empty queue 24/7.

Quick Math Check #

With long polling set to 20 seconds, 2 workers would only make ~8,640 requests per day (2 * 60 * 60 * 24 / 20) — that’s ~259k requests a month, well under the 1 million free quota. Combine that with your actual task requests, and you’ll stay well within limits.

内容的提问来源于stack exchange，提问作者helloworld