server load, php scripts

[Ninjakreborn]

I am getting a little worried with how this is turning out.  I have a script setup that does updating with data in a database, it does some date calculations, and based on a series of events, it changes the amount of time left for something to be activated inside the database.
I had this only on paid accounts, everytime they log in, it checks and calculates how many days they have remaning and updates the database, with safety areas in place, to make sure that there are no errors with it later.
Now I see I have to run the same script again, with the same setup, to test for that users recent entries of found items, and for lost items, I have to be able to auto update all of these things.  Regularly, and I am afraid the server will overload or crash, how can I do this, without overloading the server, I will reformat my script later, and try to avoid this, maybe with less database calls, optimize my script some more, but if thousands of people start logging, in it's going to kill the server, if it's running that much everytime someone logs in, but there is a lot that needs done to keep everything running smoothly, and automatic.

I was given advice on the script earlier, tbu I don't want to take the chance of it breaking the script it took me awhile to get this covering all angles, and checking properly, and the saem situation goes for lost and found postings, I can copy and paste this same code, and jsut check different fields in a different table for it to do the same thing.

[code]// start
if($_SESSION['controller'] === true) { // updates paid time period
$select = "SELECT * FROM userinfo WHERE id = '$_SESSION[id]';";
$query = mysql_query($select);// query for info
$row = mysql_fetch_array($query); // fetch array
if ($row['timeperiod'] != "none") { // check status of timeperiod
$currentdate = date("m/d/y");// get's todays date
$paydate = $row['paydate']; // get's db pay date
$currentdate = strtotime($currentdate); // test later with later date
$paydate = strtotime($paydate);
$datetoupdate = date("m/d/y");
$number_days = floor(($currentdate - $paydate)/86400); // 86400 = seconds per day
$updatedversion = $row['timeperiod'] - $number_days; // new time period
$checkforupdate = "SELECT timeperiod FROM userinfo WHERE id = '$_SESSION[id]' AND timeperiod != '$updatedversion';";
$checkquery = mysql_query($checkforupdate);
if ($checkrow = mysql_fetch_array($checkquery)) {
$update = "UPDATE userinfo SET timeperiod = '$updatedversion', paydate = '$datetoupdate' WHERE username = '$_SESSION[username]';";
$query2 = mysql_query($update);
}
} // Closes check for timeperiod equaling none.
$selectinfo = "SELECT * FROM userinfo WHERE id = '$_SESSION[id]' AND timeperiod <= '0';";
$query3 = mysql_query($selectinfo);
if ($rowforupdate = mysql_fetch_array($query3)) {
$paid = "no";
$paypalid = "not applicable";
$paydate = "not applicable";
$timeperiod = "none";
$updatepayinfo = "UPDATE userinfo SET paid = '$paid', paypalid = '$paypalid', paydate = '$paydate', timeperiod = '$timeperiod' WHERE id = '$_SESSION[id]';";
$query4 = mysql_query($updatepayinfo);
}// closes row to update payement information when number is 0 or below
}// closes test to update paid[/code]if someone sees a way to cut down the number of database calls, and they KNOW what they are doing then I will appreciate the help, if you don't understand every word of every line of code don't try it'll just break it.  The areas are all correct, and this code does what I want it to do, it updates the database properly, and it only does so if the right circumstances are met, but I am afriad running this each login, plus running it again after that for found posts and lost posts, it's going to kill the server.

[HeyRay2]

[quote]I can copy and paste this same code, and jsut check different fields in a different table for it to do the same thing[/quote]

Then copy and paste the code, make the changes and try it out.

Making multiple database calls will not hurt your database, and as long as you have a decent server, it should be able to handle the load with multiple users.

[quote]I was given advice on the script earlier, tbu I don't want to take the chance of it breaking the script it took me awhile to get this covering all angles.[/quote]

If you're not willing to try things out for fear of breaking your script, then I would suggest making a "test" copy of your database and script and trying different things out there.

Otherwise, no amount of suggestions from anyone here will help you if you're not willing to give them a try... ;)

[Ninjakreborn]

It's not that, I tested this out before, The reason I am afraid is for it to uncover hidden glitches.  The first time I fixed the script it was working, when I put it under heavier testing I noticed that it was having slight problems depending on certain circumstances.  I can try different things, and test them, but I am afraid something hidden, some kind of miscalculation that only happens under specific circumstances I am unable to cover.

[freakus_maximus]

I am not going to suggest you change your script.

I'm not sure why you are executing the script for found or lost posts since you have done it once on login. But it just seems your end goal is to validate that the person logged in should have 'paid' access. If that is true, then just set a session variable on a validated login and paid status that allows them the access.

That would cut your server overhead down 2/3rds since you would only need to execute it at login.

[Ninjakreborn]

No I have everything like that worked out.
Someone can sign up for a free account.
Here is the thing.
they are free.
in the database paid is set to no
and the timeperiod is set to none
if they pay it's yes and 30 or 365 depending on how much they paid
also the date the paid is recorded.
When they log in, if the timeperiod is NOT none then it records the date, and takes the date from teh database, and compares them, it get's the number of days in between the last date, and today.  Then it updates it, and changes the timeperiod, to match how many active paid days they have left, an dupdates the date to today.  If they log in again today then it does nothing, but tomorrow it would subtract 1 more.  It keeps doing that, until the day they login, the timeperiod goes 0 or below.  Then it chnages it all in the database to unpaid status.  Everything is automatic thus far like she wanted.  Now I have it where people can post found items, or lost items.  Found items have a 100 day lifespan, lost items have a 30 day lifespan.  I am running the same operations on those, so one someone logs in, there posts' associated with that user, are updated to show the current posting setup.  THat is what is going on now, I need to calculate all of this, and the login is the best place.  UNLESS I just set it in the admin, where she can click one button, to automatically update all the existing entries, but that alone could kill the server.  If there are 6000 entries, and she clicks a button and it starts doing the database calls necessary to update all of those, it could be murder on the server, but then if it's happening a little at a time when people login, it shouldn't matter, I am trying to come up with a way to approach this.

[king arthur]

Why do you need to keep updating the number of days a user has left in their paid time? Why not just calculate the date the paid time runs out, by doing "time() + x" where x is either 30 * 24 * 60 * 60 or 365 * 24 * 60 * 60, and storing that in the database as a timestamp.  Then when they log in, if the current timestamp is more than the one in the database, their paid time has run out. No need to keep calculating it and inserting it back each time.

[Ninjakreborn]

That sounds inviting but what about showing them how many day's they have left??

[Ninjakreborn]

Also if I try to do that with the posts, I have to show them the time period they have left on there post's because I might end up allowing them to reupdate it, if they want to try and give it a longer lifespan before it runs out.

[ryanlwh]

then you can just calculate how many days are there between the end date and today's date.

[Ninjakreborn]

[code]then you can just calculate how many days are there between the end date and today's date.[/code]
That was what I was trying to do in the beginning,
The due date and today's date, today's date is set in the database, each time it checks today's date against the last updated date, and changes the timeperiod.
or are you meaning something else, can you elaborate a little more, so I can get these ideas in my head, I like where this is going?

[king arthur]

I would always try to design a database so that it stores the minimum amount of data you need to be able to do the task in hand, i.e. I try never to store any redundant data - that which can be calculated from the data you already have need not be stored. It looks to me like all you really need to store is the time the paid period runs out. Everything else can be calculated from that whenever you need to, and only when you need to. If you have as a timestamp, the date the paid period runs out, just subtract the current timestamp (time()) and that's the number of seconds till the paid time runs out. Divide by number of seconds in a day and you have the number of days left. This doesn't need to be stored back in the database because it can always be calculated.

[ryanlwh]

if you store the end date as a DATE datatype:
[code]SELECT DATEDIFF(end_date,NOW()) FROM table[/code]
This will give you the number of days between today and end date