Does the way you write cronjob affect the performance?

@koushik355

It really depends on what the cron jobs are doing.

Using sleep to delay the start of the next cron job will allow resource usage to wind down if you’re doing something that’s resource intensive, which may provide better performance if the cron job will be using quite a bit of CPU.

For example, if one of the cron jobs is copying a large number of files from location X to location Y, it may be beneficial to delay the next cron job from running for a short period of time. Likewise, if you’re doing something really intensive that would cause CPU usage to rise, I/O wait to rise, etc – then yes, delaying the execution of the next cron job would be wise.

That being said, you may be better off simply setting up the delay in the cron job itself as opposed to in the command(s) being executed by the cron job.

Using:

* * * * *

… is equal to run every minute. You could setup more of a waterfall effect with the cron jobs and use the built in functionality of cron to simply manage the delay.

For example, you could run one every two minutes, one every four minutes, one every eight minutes, etc – you’d simply need to modify the first * and add a /# to it.

i.e. to run every second minute, you could use:

*/2 * * * * /path/to/script

The above will run 30x every 60 minutes (1 hour) – or every second minute.

For every 5 minutes, you could use:

*/5 * * * * /path/to/script

That’ll run 12x every 60 minutes (1 hour) – or every fifth minute.

Hi Jonathan, thanks a lot for taking time to write the answer. Much appreciated, brother. Here is what I am trying to achieve. I want to run the same script more than within a minute. Running it 3 times would be better. And yes, the process can be intensive because it will be sending emails to a bunch of users using postfix. What you think I should do to achieve that? Thank you very much for your help.

Heya all,

When evaluating the performance impact of the two cronjob cases you described, it is essential to consider how the tasks are scheduled and executed. Let’s break down both cases to understand their potential impact on system performance.

1st Case: All Jobs Scheduled Every Minute

* * * * * executer /path/to/job1
* * * * * executer /path/to/job2
* * * * * executer /path/to/job3
* * * * * executer /path/to/job4
* * * * * (sleep 30; executer /path/to/job1)
* * * * * (sleep 30; executer /path/to/job2)
* * * * * (sleep 30; executer /path/to/job3)
* * * * * (sleep 30; executer /path/to/job4)

2nd Case: Tasks with Sleep Intervals

executer /path/to/job1
(sleep 30; executer /path/to/job1)
executer /path/to/job2
(sleep 30; executer /path/to/job2)
executer /path/to/job3
(sleep 30; executer /path/to/job3)
executer /path/to/job4
(sleep 30; executer /path/to/job4)

Analysis

1st Case:

• Execution Frequency: Every minute, all eight jobs (four immediate, four with a 30-second delay) are scheduled.
• Concurrency: Each job runs every minute, and the second batch of jobs starts 30 seconds later. This means there could be overlapping execution if any job takes longer than 30 seconds to complete.
• System Load: The system will experience a burst of activity at the start of each minute, followed by another burst 30 seconds later.

2nd Case:

• Execution Frequency: There is no clear timing defined in the crontab format here. Assuming each pair of commands (job1 and its sleep variant) is intended to run in succession without explicit timing control, this setup implies a sequential rather than periodic execution unless otherwise specified.
• Concurrency: The jobs run one after another with a 30-second delay in between each job and its subsequent sleep execution.
• System Load: The load is more spread out over time since each job and its delayed counterpart are not clustered together in a minute’s span but are spaced by sleep commands.

Performance Considerations

• Concurrency and Overlap: In the first case, running all jobs every minute can cause significant CPU and I/O load spikes if the jobs are resource-intensive, as they run concurrently.
• Scheduling and Spacing: The second case suggests a sequential execution model with a sleep delay, which typically reduces the chances of overlapping executions and can lead to a more consistent system load.

Recommendations

1. Determine Job Duration and Resource Usage: If the jobs are short-lived and light on resources, the first case might not cause noticeable performance issues. However, if they are resource-intensive or take longer to complete, the second case’s staggered execution is preferable.

2. Monitor System Load: Use tools like top, htop, or iostat to monitor the system’s performance under both configurations to see the real-time impact.

3. Consider Combining the Approaches: You could combine the benefits of both cases by carefully scheduling jobs to avoid overlaps while maintaining regular intervals. For example, staggering job start times using sleep but with less frequent cron scheduling:

* * * * * executer /path/to/job1
* * * * * (sleep 15; executer /path/to/job2)
* * * * * (sleep 30; executer /path/to/job3)
* * * * * (sleep 45; executer /path/to/job4)

Conclusion

The performance impact will vary based on the nature of the jobs and the system’s capacity. Generally, spreading out the job execution (as implied by the second case) can lead to better performance and more stable system load, especially for resource-intensive tasks. However, if the jobs are lightweight, the difference may be negligible. Always test both configurations in your specific environment to determine the best approach.