Why is it so bad to work with PHP script continuously?

Question

I have a map. On this map, I want to show live data collected from several tables, some of which have an amazing number of rows. Needless to say, getting this information takes a lot of time. In addition, pinging is used. Depending on which servers are offline or remote, the collection of this data can vary from 1 to 10 minutes.

I want the map to be fast and responsive, so I decided to add a new table to my database containing only the data that the map needs. This means that I need a background process to constantly update the information in my new table. Of course, the capabilities of Cron are an opportunity, but I want the data to be updated as soon as the previous interval has ended. And what if the number of offline IP addresses suddenly pops up and the cycle takes longer than the Cron job interval?

My own solution is to create an endless loop in PHP that runs on the command line. This cycle will update the data for the map in MySQL, as well as write other useful data, such as cycle time and failed attempts on pings, etc., and then restart after a short pause (a few seconds).

However - people have repeatedly told me that the PHP script works forever - this is BAD. After a while, it will run gigabytes of RAM (and other terrible things)

In part, I am writing this question to confirm whether this is true, but some tips and tricks on how I will write a clean loop that does not leak memory (if possible) will not be good. Opinions on this matter will also be appreciated.

The answer that I feel sheds light on the question that I will indicate as correct.

Answer 1

The loop should be in one script that activates / calls the actual script as another process ... like cron.
Thus, even if a memory leak and accumulated memory accumulate, it will / should be free after each cycle.

Answer 2

However - people have repeatedly told me that the PHP script works forever - this is BAD. After a while, it will run gigabytes of RAM (and other terrible things)

That was very true. Previous versions of PHP had terrible garbage collection , so lengthy scripts could easily accidentally consume much more memory than they actually used. PHP 5.3 introduced a new garbage collector that can understand and clear circular references, which is the cause of the memory leak number book. It is enabled by default. Check out this link for more info and good schedules.

As long as your code takes measures to allow the variables to leave the scope at the appropriate time and otherwise cancel variables that will no longer be used, your script should not consume unnecessary amounts of memory just because it is PHP.

Answer 3

I don’t think this is bad, like everything that you want to work constantly, you need to be more careful.

There are libraries that will help you in this task. Check out System_Daemon , which released RC 1 a little over a month ago, which allows you to "set parameters such as maximum RAM usage."

Answer 4

Instead of starting an infinite loop, I will be tempted to go with the cron parameter, which you specify in conjunction with a database table record or a flat file that you will use to store the “currently active” status bit to ensure that You did not have overlapping processes trying to work simultaneously.

As long as I understand that this would mean a little delay before you perform the following iteration, this is probably the best idea, since:

• This will allow the DBMS to perform any pending updates with low priority, etc., which may be suspended due to the amount of activity you are performing.

• Even if you carefully turned off all the temporary variables that you used, it is still possible that PHP will “leak” the memory, although the latest improvements (5.2 introduced a new memory management system and garbage collection, was redesigned in 5.3), hopefully means That is less of a problem.

In general, it will also be easier to cope with other problems (if the connection to the database is temporarily disconnected due to a configuration change and restart, for example), if you use the cron approach, although in an ideal world you would somehow in your code . (However, the last time I checked, it was far from an ideal world.)

Answer 5

At first, I don’t see how you need a script daemon to provide the described functions.

Cron works, of course, are possible, but I want the data to be updated as soon as the previous interval has ended

Neither a cron job nor a daemon can solve the problem (unless the daemon becomes a receiver for scripts). I would create a dissociated process when data is available using a lock strategy for aoid concurrency.

Long PHP scripts are not internally bad, but the reference to counting the garbage collector is not related to all possible scripts for clearing memory, but in later implementations there is a more advanced collector that should clear much more (circular check reference).