PHP is meant to die. It doesn’t mean that it will disappear into nothingness, it just means that your PHP code can’t run forever; The core PHP feature follows the most simple programming workflow: get input data, process it, display the output, and die.
…
If you want to keep [PHP] processes running forever they will crash, and will do it really fast under load, because of known or unknown reasons. That’s nothing you can really control, it’s because PHP is meant to die. The basic implementation, the core feature of the language, is to be suicidal, no matter what.
Really interesting read (with follow-up) for anyone doing PHP development involving continously running PHP scripts. Highly recommended.
Been running a WebSocket Server — implemented via the excellent Ratchet which is built on top of the aforementioned React — for a few days now and with each connection that connects & closes a tad of memory is left occupied indeed (viz. opening and closing a connection doesn’t result in the same memory usage as before the connection was created) … looks like I’ll have to keep an eye on this.
We do run into this problem as well.
Our ‘hack’:
– Our “continuously running processes” are started by a cronjob that’s sheduled every minute. First thing the script does is checking a .pid file to see if a similar process is already running or not, to prevent it from running twice.
– The script does its backend jobs (typically RabbitMQ events) in a while loop.
– During that while loop we keep an eye on the time (and exit() if it’s been running for say > half an hour), or if memory usage gets big. (The cronjob will restart it in max. 1 minute.)
– Oh, and we increased the memory limit :).
Neat trick. Thanks for sharing!
a nice hack is start a second php process (exec) in the while loop . This second process (thread) should do the real processing and should die when finished, the other one is just an almost empty loop and therefore doesnt realy use (and leak) memory.
To address the “long run” problem you may follow the advises of Jurriaan and Ixer. Instead of relay on a cron job you may use systemd or upstart, or another daemon manager. You can easily daemonize your PHP scripts using this approach. RabbitMQ or maybe Disque, or even ZeroMQ, are all suited to be used as message brokers. You can start a pool of thread inside your daemon to handle the messages using something like ko-process or AzaThread (both available as composer packages). To me doesn’t make any sense to use another language to write your daemons code, since you can’t reuse your PHP object model. Of course PHP is not the best language to write daemons, Go, Rust, C/C++, Scala or even Swift are better alternatives, but unless your are dealing with performance issues, I would stick with PHP.
THE FACTS
I have a PHP script running for years in a raspberry pi, running raspbian, 24/7/365.
Is 100% stable, never crash.
That question i got 5 years ago, but the truth is that IT JUST FUCKING WORKS 100% WITH NO PROBLEM.
My script start via cron, i send commands via socket to my php daemon.
The script have a while that keeps running forever, using usleep() to avoid php using 99% of CPU.