NOTE: Please do not rely on this functionality anymore. Starting with mailwizz 22.214.171.124 the send-campaigns command has been improved so much that there is no need for Redis or the like anymore so in the future we will remove redis from mailwizz entirely. Since version 1.3.5, MailWizz adds experimental support for using queues with Redis. Using regular cron job sending, on a linode with 2 cores and 2GB of ram(~512 available), sending a campaign with 10k subscribers at once took as shown below: Code: [root@work-01 ~]# time /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns real 17m40.299s user 8m1.417s sys 2m53.203s When redis queue has been enabled, sending same amount of emails, 10k, took as shown below: Code: [root@work-01 ~]# time /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns real 4m6.028s user 2m26.167s sys 0m53.307s As we can see, sending with redis queue is considerably faster, ~4 times faster on a considerably small machine. In order to use this sending method, your server needs to meet the following requirements: 1. Redis server 2. PHP's pcntl's extension installed and enabled with no function disabled. 3. If possible, install php's native client for redis. 4. command line/ssh access so that you can run various commands. See https://forum.mailwizz.com/threads/redis-install.205/ for a guide on how to install #1 and #3. In order to enable sending via this method, firstly we need to enable and configure the Redis Queue from mailwizz backend, so go to Backend -> Settings -> Queue and do the needed adjustments and enable it, then save the changes. Once the redis queue is ready for use, we need to decide which delivery servers are going to use the queue. If you try to edit a delivery server now after the queue feature has been enabled, you will notice a new field, called "Use queue". You need to set this field to YES for the servers that you want to use this sending method. Do that and then save your delivery server. (P.S: you can have servers using queue and servers doing regular delivery without queue, both work just fine in the same time) Now the system is ready to queue all your emails in the redis server when campaigns are being sent via the delivery servers you have choosen to use the queue on. If you send a test campaign, you will notice that sending it is going to be blazing fast, like really fast that you'll think something is wrong. Well, there's nothing wrong, it's so fast because we just queue the emails in the redis server, we are not sending them at all. In order to do the actual sending, we need some kind of daemon that will run permanently and read the redis queue, pick the campaign emails, send them and then empty the queue. For this exact reason, a new mailwizz command line command is available. If from command line you run: Code: /usr/bin/php -q /absolute/path/to/apps/console/console.php you will see something like: Code: [root@work-01 ~]# /usr/bin/php -q /home/domain/public_html/apps/console/console.php Yii command runner (based on Yii v1.1.16) Usage: /home/domain/public_html/apps/console/console.php <command-name> [parameter s...] The following commands are available: - archive-campaigns-delivery-logs - archivecampaignsdeliverylogs - bounce-handler - bouncehandler - daily - feedback-loop-handler - feedbackloophandler - hello - migrate - option - process-delivery-and-bounce-log - process-subscribers - processdeliveryandbouncelog - processsubscribers - queue - redisqueue - send-campaigns - send-transactional-emails - sendcampaigns - sendtransactionalemails - update To see individual command help, use the following: /home/domain/public_html/apps/console/console.php help <command-name> So the command that interests us is the queue command. Please note that this is not a command that should be placed in the cron jobs to be called once at x minutes. This is a daemon that once started it will run permanently and you should not have more than one instance of it running in the same time. It can be called from command line like: Code: /usr/bin/php -q /absolute/path/to/apps/console/console.php queue --workers=10 --interval=5 --verbose=0 The --workers param means how many separate processes will be started to check your queue. Please note that all these processes will run in parallel and might eact a considerable amount of ram and cpu if the number of workers is too high. This is PHP, not the best tool for this kind of stuff. The --interval param, is the number of seconds between the queue checks. In the above case, the queue will be checked once at 5 seconds by each worker. The --verbose param is a debug flag, if it's set to 1, you can see how and what is processing. Once you call this command (you should call it with --verbose=1) you will see how it starts processing all the emails from the redis queue. Once you are sure this works as expected you can kill the queue process so that you can later start it again in background. To do this, simply run: Code: ps aux | grep queue Which will return something like: Code: [root@work-01 ~]# ps aux | grep queue root 21641 0.0 0.5 550952 11116 ? Ss Feb04 2:18 /usr/bin/php... Where 21641 is the process PID and we can kill it with: Code: kill -9 21641 Then we can start the process again and send it in background with following command: Code: nohup /usr/bin/php -q /absolute/path/to/apps/console/console.php queue --workers=10 --interval=5 --verbose=0 >/dev/null 2>&1 & After you do this, the process will run till you kill it, till the server reboots or till it dies because of some fatal error, like insufficient memory or the like. To recap, when using redis queue, the cron job that runs once a minute, the one that calls send-campaigns will load your campaigns from database and instead of sending the emails directly, it will store those emails in the redis queue from where they will be later picked up by the queue daemon that you have started and it runs in background and this daemon is the one that does the actual delivery. Each worker will process 100 emails at once, so when you have 10 workers, you'll process 1k emails at once. Keep this in mind so that you don't use all your server memory because of this. That's it. If any questions related to this, please ask but keep in mind, this is still experimental stuff. For me it worked fine while i tested it but I recommend you to test this enough before you rely on it. Thanks.