@@ -462,22 +462,23 @@ Deploying to Production
462
462
463
463
On production, there are a few important things to think about:
464
464
465
- **Use Supervisor to keep your worker(s) running **
465
+ **Use a process manager like Supervisor or systemd to keep your worker(s) running **
466
466
You'll want one or more "workers" running at all times. To do that, use a
467
- process control system like :ref: `Supervisor <messenger-supervisor >`.
467
+ process control system like :ref: `Supervisor <messenger-supervisor >`
468
+ or :ref: `systemd <messenger-systemd >`.
468
469
469
470
**Don't Let Workers Run Forever **
470
471
Some services (like Doctrine's EntityManager) will consume more memory
471
472
over time. So, instead of allowing your worker to run forever, use a flag
472
473
like ``messenger:consume --limit=10 `` to tell your worker to only handle 10
473
- messages before exiting (then Supervisor will create a new process). There
474
+ messages before exiting (then the process manager will create a new process). There
474
475
are also other options like ``--memory-limit=128M `` and ``--time-limit=3600 ``.
475
476
476
477
**Restart Workers on Deploy **
477
478
Each time you deploy, you'll need to restart all your worker processes so
478
479
that they see the newly deployed code. To do this, run ``messenger:stop-workers ``
479
480
on deploy. This will signal to each worker that it should finish the message
480
- it's currently handling and shut down gracefully. Then, Supervisor will create
481
+ it's currently handling and shut down gracefully. Then, the process manager will create
481
482
new worker processes. The command uses the :ref: `app <cache-configuration-with-frameworkbundle >`
482
483
cache internally - so make sure this is configured to use an adapter you like.
483
484
@@ -633,6 +634,91 @@ config and start your workers:
633
634
634
635
See the `Supervisor docs `_ for more details.
635
636
637
+ If a worker dependency like your database server is down, or timeout is reached,
638
+ you can try to add :ref: `reconnect logic <middleware-doctrine >`, or just quit
639
+ the worker if it receives too many errors with the ``--failure-limit `` option of
640
+ the ``messenger:consume `` command.
641
+
642
+ It is possible to end up in a situation where the supervisor job gets into a
643
+ FATAL (too many start retries) state when trying to restart when something is
644
+ not yet available. You can prevent this by wrapping the Symfony script with a
645
+ shell script and sleep when the script fails:
646
+
647
+ .. code-block :: ini
648
+
649
+ ; /etc/supervisor/conf.d/messenger-worker.conf
650
+ [program:messenger-consume]
651
+ command =sh -c " /php /path/to/your/app/bin/console messenger:consume async --time-limit=3600 || (sleep 30 && false)"
652
+ ...
653
+
654
+ .. _messenger-systemd :
655
+
656
+ Systemd Configuration
657
+ ~~~~~~~~~~~~~~~~~~~~~
658
+
659
+ While Supervisor is a great tool, it has the disadvantage that you need system
660
+ access to run it. Systemd has become the standard on most Linux distributions,
661
+ and has a good alternative called user services.
662
+
663
+ Systemd user service configuration files typically live in a ``~/.config/systemd/user ``
664
+ directory. For example, you can create a new ``messenger-worker.service `` file. Or a
665
+ ``
[email protected] `` file if you want more instances running at the same time:
666
+
667
+ .. code-block :: ini
668
+
669
+ [Unit]
670
+ Description =Symfony messenger-consume %i
671
+
672
+ [Service]
673
+ ExecStart =php /path/to/your/app/bin/console messenger:consume async --time-limit =3600
674
+ Restart =always
675
+ RestartSec =30
676
+
677
+ [Journal]
678
+ Storage =persistent
679
+
680
+ [Install]
681
+ WantedBy =default.target
682
+
683
+ Now, tell systemd to enable and start one worker:
684
+
685
+ .. code-block :: terminal
686
+
687
+ $ systemctl --user enable [email protected]
688
+
689
+ $ systemctl --user start [email protected]
690
+
691
+ Then enable and start another 19:
692
+
693
+ .. code-block :: terminal
694
+
695
+ $ systemctl --user enable messenger-worker@{2..20}.service
696
+
697
+ $ systemctl --user start messenger-worker@{2..20}.service
698
+
699
+ If you would change your service config file, reload the daemon:
700
+
701
+ .. code-block :: terminal
702
+
703
+ $ systemctl --user daemon-reload
704
+
705
+ Restart all your consumers:
706
+
707
+ .. code-block :: terminal
708
+
709
+ $ systemctl --user restart messenger-consume@*.service
710
+
711
+ Logs are managed by journald and can be worked with using the journalctl
712
+ command, but you do need elevated privileges (sudo) for that:
713
+
714
+ .. code-block :: terminal
715
+
716
+ $ sudo journalctl -f [email protected]
717
+
718
+ $ sudo journalctl -f _UID=$UID
719
+
720
+ See the `systemd docs `_ for more details.
721
+
636
722
.. _messenger-retries-failures :
637
723
638
724
Retries & Failures
@@ -1541,6 +1627,8 @@ middleware and *only* include your own:
1541
1627
If a middleware service is abstract, a different instance of the service will
1542
1628
be created per bus.
1543
1629
1630
+ .. _middleware-doctrine :
1631
+
1544
1632
Middleware for Doctrine
1545
1633
~~~~~~~~~~~~~~~~~~~~~~~
1546
1634
@@ -1663,4 +1751,5 @@ Learn more
1663
1751
.. _`Enqueue's transport` : https://github.com/sroze/messenger-enqueue-transport
1664
1752
.. _`streams` : https://redis.io/topics/streams-intro
1665
1753
.. _`Supervisor docs` : http://supervisord.org/
1754
+ .. _`systemd docs` : https://www.freedesktop.org/wiki/Software/systemd/
1666
1755
.. _`SymfonyCasts' message serializer tutorial` : https://symfonycasts.com/screencast/messenger/transport-serializer
0 commit comments