"Cronless crons"

[wrux]

Ah, we are talking about different things - kind of.

The idea of cronless crons - in this instance - was to update all player and other related stuff typically every minute, five minutes, every hour, every day, IIRC.

Yea I was just trying to show a different way of doing it. When I had a mccodes game I ended up removing the super intensive cronjobs (5, 10 mins) for something similar to what i just posted

[Florian_]

I've actually tested the Magictallguy Cronless crons, And they work perfectly well...

They do what they need to do, And cause less strain on the server than normal MCCodes crons.

[SRB]

I've actually tested the Magictallguy Cronless crons, And they work perfectly well...

They do what they need to do, And cause less strain on the server than normal MCCodes crons.

Do you have benchmarks to prove those claims?

[gamble]

Do you have benchmarks to prove those claims?

I would love to see the tests as well just to see how it actually improves it if in fact it does!

[Magictallguy]

My code was a fork from KyleMassacre's 1min cron replacement.. I've just evolved it from there to mark in for the other crons.

Dependant on server, it can cause more strain, it can have a negligible impact. As far as I'm aware though, because the crontab is part of a different system, my Cronless Crons will *always* cause more strain. Though, as previously mentioned, impact my be negligible assuming you have a decent enough webserv..

I've since evolved my Cronless Crons further and my server barely notices the different - it now runs 1min, 5min, 15min, 60min, 12hour, 24hour, 7day and not a single complaint from each - though I believe that may have something to do with the fact that I make sure *nothing* fires at the same time.. Imagine all of those firing at once? Goodbye less-than-adequate server!

[Guest]

I've worked on games that have > 40 crons running at different intervals, crons themselves I don't think are hard on the server, it's the code and what the code does that makes the difference, in my experience i've never had issues running crons so I don't think I would use this.

[KyleMassacre]

My code was a fork from KyleMassacre's 1min cron replacement.. I've just evolved it from there to mark in for the other crons.

Dependant on server, it can cause more strain, it can have a negligible impact. As far as I'm aware though, because the crontab is part of a different system, my Cronless Crons will *always* cause more strain. Though, as previously mentioned, impact my be negligible assuming you have a decent enough webserv..

I've since evolved my Cronless Crons further and my server barely notices the different - it now runs 1min, 5min, 15min, 60min, 12hour, 24hour, 7day and not a single complaint from each - though I believe that may have something to do with the fact that I make sure *nothing* fires at the same time.. Imagine all of those firing at once? Goodbye less-than-adequate server!

 

You must have me confused there buddy :p I believe Cronus made a cron replacement

[Magictallguy]

You must have me confused there buddy :p I believe Cronus made a cron replacement

Ah, my apologies..

"My code is a fork from whoever originally wrote the 1min replacement" :P

[KyleMassacre]

Ah, my apologies..

"My code is a fork from whoever originally wrote the 1min replacement" :P

No need to apologize to me. I just don't want people thinking I made something if I didn't

[Coly010]

Quick question. I've implemented "Cronless Crons" into Chaos Era but I've hit a slight snag. I have a max energy (similar to mccodes). I have it add 10 energy per update to each user, but how can i limit their energy to their max energy?

Is it a case of setting up a loop and going through each user, checking if their energy is greater than their max energy and then setting it to their max?

[Dayo]

you could do something like

UPDATE `userTable` SET `energy` = `maxEnergy` WHERE `energy`>`maxEnergy`

run that after the update energy SQL.

[Coly010]

[MENTION=64684]Dayo[/MENTION] wow i feel slightly stupid now. It was actually quite simple, thanks :)

[Jax]

Why run an extra query to fix something that you have just run?

Assuming you have; for example:

UPDATE users SET energy = energy + max_energy / 6;

as one query, you would probably think that:

UPDATE users SET energy = max_energy WHERE energy > max_energy;

is suitable to correct any problems with the first query, yet you can kill two birds with one stone with the rather elegant:

UPDATE users SET energy = LEAST(max_energy, energy + max_energy / 6);

LEAST() and GREATEST() are handy functions that should not be neglected.

Why do it this way? One query, means less context switching between PHP and SQL, it means less time with the table, or pages within the table being locked thus potentially preventing anybody else from accessing these records; being SQL, it prevents race conditions when it would be possible for a user to actually access more energy than their theoretical maximum energy. etc. etc.

[Coly010]

Why run an extra query to fix something that you have just run?

Assuming you have; for example:

UPDATE users SET energy = energy + max_energy / 6;

as one query, you would probably think that:

UPDATE users SET energy = max_energy WHERE energy > max_energy;

is suitable to correct any problems with the first query, yet you can kill two birds with one stone with the rather elegant:

UPDATE users SET energy = LEAST(max_energy, energy + max_energy / 6);

LEAST() and GREATEST() are handy functions that should not be neglected.

Why do it this way? One query, means less context switching between PHP and SQL, it means less time with the table, or pages within the table being locked thus potentially preventing anybody else from accessing these records; being SQL, it prevents race conditions when it would be possible for a user to actually access more energy than their theoretical maximum energy. etc. etc.

I must look into LEAST() and GREATEST() and see how they can help me, maybe in other situations.