I think the solution I would try is:
- Use multiple queue workers (to get concurrent jobs running).
- This can be scaled out on multiple servers, with more queue workers running, as needed
- Have each job take care a phone number. So each job will take one phone number and send each text message for that phone number (maybe with a call of
sleep(1);between each SMS send)
Adding a 2nd second won't really help. Rather than being an issue of database performance (it might be, but likely isn't), it's mostly an issue of how databases work with transactions and timing.
Note: You'll very likely accidentally run a job more than once when you use multiple workers against the database driver for queue workers. I'd investigate using another queue worker type. Forge comes with Beanstalk on the server, that might be a good place to start.
I generally use AWS's SQS as it's very cheap and is one less piece of software to manage. However, it has it's own caveats that you may run into in terms of job run-time - you'll want to increase the default SQS queue's Visibility Timeout (or change it per-job to be something high).
The method I described above would have less queue jobs (one job per phone number) but take more time per job ( # SMSes to send * (1 second + api call time) ). Just be sure not to set a total job time allowed (don't set a --timeout flag on queue workers).