Deploying Laravel app to both app and back-end (queue) servers question

@karni It’s going to be hard for any one to answer because we don’t know what your application does, how heavy it uses queues, your hosting provider, or budget.

Gotcha @martinbean , should have anticipated that, sorry.

For my VPSes I'm using: 1GB RAM, 1Ghz CPU, 50GB SSD. They're relatively cheap, as it's a local provider, they cost me only $8 (without tax, which is VAT and I'm a registered business).

My blog currently has rougly 30k views montly (10uu/month). It's wordpress and it's going to trash. I'm putting up a niche portal with blog, forum, and a search capability of... let's say businesses in my country.

I intend to use the queues mostly for things like mailing, scheduled jobs, later perhaps for some indexing of the businesses. I don't anticipate the queues will be super busy. I would also like to use one of the queues for collecting statistics, and one for conducting auctions (seeling ad space).

Hope this gives a bit of a clearer picture. This is my first business undertaking, and I've spent a lot of time choosing technologies (Laravel, Vue, Redis for cache and socket.io, Postgres for db).

Thanks!

EDIT: I recognize for Redis cache I may later require upscaling to say 2GB of RAM.

The question regarding where to put my queue still holds, but I've found in another threat regarding deployment that says - yes, artisan up/down or envoyer/similar are the way to go regarding deployment.

Laravel workers are basically instances of the application itself, running on the CLI instead of via PHP-FPM.

The nice part about this is that you can create just another of the one (or multiple) stateless app servers and run your workers on that! (Budget permitting, of course).

My strategy for that is:

1. Have a 1+ application servers behind a load balancer for web requests,
2. Have 1+ other application servers NOT in the load balancer rotation, used for queue workers.

To make it simpler, I'll sometimes provision exactly the same server for workers and web (so a worker server might also have nginx/php-fpm on it, just un-used).

Thank you @fideloper , I'm pleased to see you reply to my question :)!

Your suggested strategy makes sense, thank you. Yeah, I also thought about that - Forge provisions servers with everything at once (mysql, postgres, redis, beanstalkd, regardless of what you plan using). On the upside, you can provision and not worry whether it has what you need. But - I guess one should lock the instances down with firewall, if some services are unused.

Yep, and you can disable services on newer servers using the systemctl command:

# Stop nginx
sudo service nginx stop # equivalent to sudo systemctl stop nginx`

# Disable nginx from starting back up on system boot
sudo systemctl disable nginx

(That might be nginx.service instead of just nginx, I forget)

Yup! Thanks for the pointers, you've been very helpful!

Since I'll have one queue worker for now, I think I'll just put it on the Postgress back-end server (My back-end, for start, will be a server with Redis, and a second server with Postgres). Mostly because Redis is in memory.

Once the queue load increases, I'll put up a third server on the back-end.

Hope what I wrote makes sense :)