I have a question to ask, I am doing a project and I have been using Microtime and I am testing the execution times for each insert select and delete although it seems really strange as I am getting results like
to insert 100 records … ok its only adding 3 columns of data prior to what the user adds in the php form but I wanted to know whether this looks weird or not realistic to anyone and maybe someone could point me in the right direction to show actuall times of execution.
I am using the following to find the microtime()
// Randomize sleeping time
//usleep(mt_rand(100, 10000));
usleep(100);
//Microtime returns the current time as miliseconds
$msc = microtime(true);
//$msc = microtime(true)-$msc;
$msc = microtime(true) - $_SERVER["REQUEST_TIME_FLOAT"];
@nichemtktg What would you suggest I use? I want to be able to show the exact time it had taken to insert the data in the database without it showing random results
I have made adjustments I added 1 insertand it showed
$tmp ==> 0.4
$tmp ==> 0.10
I then insert 1000
$tmp ==> 0.22
$tmp ==> 0.26
based on the code below is this the results that are meant to show? I am still abit unsure whether it looks right but I hope to hear from you about it.
It’s a bit difficult to say - when you say you insert 1000, where do you change the code to do the additional inserts? As long as you set the start time immediately before the query as you (just about) have here, and then calculate the difference immediately after it, then it should be correct.
Seems a bit weird that it takes less time to insert 1000 rows than it takes to insert one row. Or is that displaying the time per row?
mysql_query(“INSERT INTO table (a,b,c) VALUES
(‘$a’,‘$b’,‘$c’‘),
(’$a’,‘$b’,‘$c’‘),
(’$a’,‘$b’,‘$c’')”);
is this the correct way to do it too get the right results? also $tmp what does that variable stand for? I hope to hear from you soon as I need to try and populate the right results to add to my report of execution times
So you need to make sure that all the queries are between the point where you note the start value of microtime(), and the point where you calculate the difference.
x = microtime();
for (l==0; l<1000; l++) {
query(whatever)
}
elapsed = microtime() - x
I’ve done this before as a type of “poor mans” benchmarking. Not the best at benchmarking if you need serious data, but easy and good enough at giving a clue.
As others have posted it’s like
$start time
code / loop with code I want to time
end of code / end of loop with code I want to time
$end time
display or log $end - $start
It seems strange that the more inserts you perform, the larger the difference in time. I’d have roughly expected that each time you multiply the inserts by ten, then the time would roughly increase by the same factor. But your figures show that going from one to ten the time increases by a factor of five, which indicates some optimisation or caching somewhere, which is good. Then when you go from ten to 100 inserts, though, the time increases by a factor of 67, and the next step by a factor of 166, when each time you’d expect it to increase by no more than a factor of ten.
Perhaps the suggestion from @mittineague above about using EXPLAIN to look at your query might point to where some improvement could be gained.
Just guessing but think the elapsed times do not match the increased inserts is because of background processes. An open SitePoint browser tab could be one cause because it periodically grabs processor time by checking for updates.
Maybe, I guess it all depends on where the OP is actually running the PHP code. Although I’d also have imagined that anyone doing time trials might have suspended as much as possible to try to reduce outside interference to the absolute minimum.
ETA - looking back at the code in post #6, if the information is still being written to a text file as well as to the database, and that operation is inside the timing, maybe that could have an effect. I’m thinking of perhaps the time taken in extending a stream file once the pre-allocated space is used up. Maybe caching and modern hardware and so on don’t have noticeable delays, maybe that code has gone now.