script processing times

[Keiichi]

for php scripts, i'm just wondering what type time length to processing a script is actually stressing a server? I see some toplist scripts on some servers that take around 15sec to process, while script like phpBB take like .04sec for a bulletin board. i don't know if they both include mysql access time, but just wondering

[Terra]

The answer is simplistic in nature but deep in dynamics and nuances...

One thing you did not define was whether the time noted were CPU or Wall time...

15 seconds Wall time could be 12 seconds sleeping in accept() mode or waiting for an outside connection to connect/process...[nbsp][nbsp]This eats memory and a connection slot, but not much else...

If the time given is CPU time, then it's a fair assumption that it's relative to the amount of horsepower required to complete the given task...

15 seconds is a tremendous amount of CPU time for one process to complete...[nbsp][nbsp]Multiply that by the number of times that PHP script is going to be hit in a minute, and you can see that it can become a problem defined by parasitic diminishing returns...

In short, when you purchase an account with us, then you are in effect giving the world permission to use our servers resources through a portal known as your web site...[nbsp][nbsp]The dynamics of this are unbelievable and random in nature...[nbsp][nbsp]With that type of responsibility, then you must play your part to make sure that your not abusing our servers by asking the world to click and execute inefficient code...

In some demented ways, I embrace Dynamic Content - because I know for fact that the 'bargain basement' hosts won't know what hit them when they discover their Cobalt RaQ servers will buckle under pressure...[nbsp][nbsp]The one's running them know little more than setting up accounts via the servers 'Control Panel'...[nbsp][nbsp]When the tidal wave recedes, they will have been washed away to become shark snacks...[nbsp][nbsp]

I make no bones about it - all this Dynamic Content is killing servers everywhere, and it takes a special kind of crew to dynamically adjust to it's demands and needs...[nbsp][nbsp]Dynamic Content is sort of like watching a two-year old throw a huge hellfire tantrum for whom can't decide exactly what it is they want...

Anyhow, our servers will kill your PHP at 20 seconds and if your program needs more than that then it is doing something wrong...[nbsp][nbsp]If you want your stuff to be interactive, then you want to keep your window to 6 seconds of runtime or less...

I'm not sure if I exactly answered your question, as you did not clearly define nor make an analysis for what the script actually does...[nbsp][nbsp]If you truly wanted to answer your own question, then the only way to do so is analyze the source code and understand exactly what it does and how it operates...[nbsp][nbsp]Once you look at the code, then you should be able to isolate inefficiencies, bad design, and just plain stupidity - which would be better off with a new algorithm...[nbsp][nbsp]That would be the first best definition of 'stressing a server'...[nbsp][nbsp]I am more lenient with a solid program that is written with as much efficiency as possible then it's runtime is mostly justified...[nbsp][nbsp]What I don't like to see is idiocy chewing up a servers resources for just plain no good reason...[nbsp][nbsp]The program authors don't really care about if it takes their routines a couple extra seconds to complete - but what they fail to see is that our servers bear the brunt of an accumulative 2 seconds throughout a 24 hour day...[nbsp][nbsp]Believe me - it adds up - quickly...

Which is more server friendly?

File:[nbsp][nbsp]war_and_peace.txt[nbsp][nbsp]15Mb
(a)
open I, "war_and_peace.txt";
@book = [i];
close I;
chomp (@book);
foreach $line (@book) { do something with each line }

or
(b)
open I, "war_and_peace.txt";
while (defined($line=[i])) { do something with each line }
close I;


The ratio for the above is 9/10 times the wrong choice will have been made in the programs you run...

All this and I haven't even had a chance to drink from my first cup of early morning coffee yet...

--
Terra
--In the end - You will get and deserve what you pay for--
FutureQuest

[Rich]

How much do we get our "fence" raised if we answer correctly? :P

Rich

[dank]

A somewhat concrete example would be a change I made recently to my PHP/MySQL calendar program.[nbsp][nbsp]Instead of a database query for each day of the month, I ran a single query for the entire month and divided the results up into an array of days, which then fed into the days as they are built.[nbsp][nbsp]That resulted in an average page creation time (wall time) going from 0.08 seconds down to 0.015 seconds, which I'd say is a pretty significant decrease in server load, no?

Dan

[Terra]

going from 0.08 seconds down to 0.015 seconds I would say that the return is very admirable, especially if that routine is hit often enough that the aggregate return is accumulative and substantial... :)

Overall, you can convey 5.33 more results back to your visitor in the same amount of time space...

This not only helps to free up the server sooner, but also gives back snappy responses to your visitors...

--
Terra
--Many times I struggle and fight for .000001% improvements in kernel syscalls that I know are going to be hit millions of times a day for which stat() and fork() are prime examples--
FutureQuest

[dank]

Glad Master Terra approves.[nbsp][nbsp]:)[nbsp][nbsp]Of course, I don't anticipate it being hit millions of times a day, but one could always dream...

Dan

[Keiichi]

phew, that was one deep explanation if i must say so myself(even though i didn't understand all of it :þ). oh, and i was talking about wall time (but they were not my scripts so i don't really know). my larger scripts takes around .02 to 2sec if i remember right