I have an application which uses queues in order to send emails.
In a production environment, should I run the queue:listen command in the same application server where the application resides? Or should I do outsorcing?
So far,I've been in a dev environment working with two command lines, one for the php artisan serve command in order to get the application running and the other for the php artisan queue:listen command. If outsorcing is better for production environment, would I have to modify my code so I can work with Beanstalkd, Amazon SQS or another?
Reference Link ::
http://laravelcoding.com/blog/laravel-5-beauty-sending-mail-and-using-queues#14-about-queues
Helped me with my approach for sending notification message to gcm and to the registered mobiles.
Related
I make a simple server using Laravel for websocket purposes using Laravel-Websocket
The server managed to run well on Laravel Forge, it's just that I can't execute the php artisan websockets:serve command on deamon.
The error message I found is
Is there anything I miss in this case?
Thank you
I want to run Cron job in BlueMix in my php web application and I not found directly any Cron concept in bluemix. So how can I perform my cron task?
In many tutorial they say workload scheduler service but this is in java and I don't understand this concept and no good tutorial about this.
For scripts that need to be called on a schedule, invoke them over HTTP from a cron job using curl or wget from a Linux host, often the one hosting the LAMP stack itself.
However, that doesn't work on a PaaS like Bluemix because you don't have shell access to any underlying VM, so the alternative is to install a cron job elsewhere on a server under your control and script it to hit your Bluemix script on a schedule.
Currently I am able to integrate the ratchet web socket chat into my laravel app locally. Normally, I will execute this command -> 'artisan serve' to use the build in laravel server.
After I integrated the ratchet, I will need to manually run another php class which starts the ratchet server in order to perform real-time chat. So I wonder: is it possible to run both servers by using the artisan serve command? So that I won't need to manually run the ratchet server class?
Actually I already tried creating a chat service provider class to execute the ratchet server class during runtime. But when I use the command artisan serve to run, it only starts the ratchet server. It will not continue to start the laravel server, it is stuck at that point...
So what exactly is php artisan serve doing? I currently have a site up and running on apache and I am trying to get a websocket framework up for real time chat. The websocket is a php daemon that runs in the background and listens for events, see the package here.
So I am using the command
php artisan serve brainsocket:start --port=8080
to start the server and everything works great, however this only works while I have the terminal open and I have read in 3-4 SO posts that artisan serve is NOT to be used in production. So how can I run the laravel package start function on port 8080 without php artisan serve, and so that it will be persistent after I close the terminal?
I'm surprised this hasn't been answered yet.
In production you want to run a real web server like Apache or Nginx.
With Nginx you would use php-fpm as your runtime and you would proxy requests to it.
Here's an example from Nginx's website.
https://www.nginx.com/resources/wiki/start/topics/examples/phpfcgi/
I now have a stable Beanstalkd and Laravel 4 Queue setup running on one machine. My question is, how can I install the Laravel 4 workers on a second machine and make them listen to my Beanstalkd? Maybe a very obvious question to some but I can't figure it out. I noticed there was a connection field in the php artisan queue:listen command. Do I have to use that?
how can I install the Laravel 4 workers on a second machine and make them listen to my Beanstalkd?
You'll need to have a working instance of your laravel application on the same server as the listener/workers.
This means deploying your application both to the web server and to server that is listening for jobs.
Then, on the listening server, you can call php artisan queue:listen in order to listen for new jobs and create a worker to handle the job.
I noticed there was a connection field in the php artisan queue:listen command. Do I have to use that?
On top of the above question, and similar to most artisan commands, you will likely also need to define which environment the queue:listen command should use:
$ php artisan queue:listen --env=production
In this way, your laravel app that is used to handle the workers (the app on the listening server) will know what configurations to use, including knowing what database credentials to use. This also likely means that both the web server and your job/listening server needs to have access to your database.
Lastly, you could also create 2 separate Laravel applications - One for your web application and one purely to handle processing job. Then they could each have their own configuration, and you'll have 2 (probably smaller?) code bases. But still, you'll have 2 code bases instead of 1.
In that regard, do whatever works best for your situation.