What exactly does Microtime() do + need advice

Hi All,

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

63.343048095703
20.723104476929
12.885093688965
32.137870788574
16.018867492676
18.256187438965

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"];

$_SERVER[“REQUEST_TIME_FLOAT”] = timestamp of the start of the request
http://php.net/manual/en/reserved.variables.server.php

I probably wouldn’t use $_SERVER[“REQUEST_TIME_FLOAT”].

Who’s to say when the request actually starts?

@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

Try this:

  $iStart = (float) microtime(true); // 
  
  // DO PROCESS  

  $tmp = microtime(true) - $iStart;
  $tmp = number_format( (float) $tmp, 2);
  echo '<br> $tmp ==>  ' .$tmp;

1 Like

What exactly does that do? line by line

I have added my code, seems like I am doing it weird because I have inserted 1000 values into the database and its showing

1519985404748.7
1519985418486.8
1519985460480.8

but when I insert 1 value it shows

26.30090713501

this can not be right… can someone show me what I am doing wrong?

$msc = (float) microtime(true);
$tmp = microtime(true) - $msc;
$tmp = number_format( (float) $tmp, 2);

//MYSQL

$name = $_POST['name'];
$email = $_POST['email'];
$qebsite = $_POST['website'];


$sql = ("INSERT INTO users (name, email, website) VALUES ('$value1', '$value2', '$value3')");

$file=fopen('Insert1.txt', 'a');

fwrite($file, $msc * 1000);

if (mysqli_query($conn, $sql)) {
	  echo "<br>";
 echo "The time it had taken to insert this data from the MYSQL database in miliseconds is"."" .$msc;
  echo "<br>";
      echo " and in seconds it is calculated at" .($msc * 1000); // in seconds;
      echo "</br>";
} else {
      echo "Error: " . $sql . "<br>" . mysqli_error($conn);
}

fclose($file);
mysqli_close($conn);


?>

In that code, you seem to assign microtime to $msc at the start of the code, and never again. Surely you need to do that around the query?

store microtime in variable 'x'
execute query
display microtime - 'x'

You also seem to write the microtime to the file before you’re executed the query, which seems strange.

1 Like

Treat the value returned from microtime the same as setting a stopwatch to microseconds

The first line should set the stopwatch value.

Perform the query.

After the query results, echo a new microtime time minus the start microtime time.

The difference is the time elapsed since starting the stopwatch.

Edit:
Check the online PHP manual for further examples of how to use microtime and also the parameters.

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.

//MYSQL

$name = $_POST['name'];
$email = $_POST['email'];
$qebsite = $_POST['website'];

$iStart = (float) microtime(true);

$sql = ("INSERT INTO users (name, email, website) VALUES ('$value1', '$value2', '$value3')");

if (mysqli_query($conn, $sql)) {
	  $tmp = microtime(true) - $iStart;
	  $tmp = number_format( (float) $tmp, 2);
      echo '<br> The time executed in miliseconds $tmp ==>  ' .$tmp;
} 
else {
      echo "Error: " . $sql . "<br>" . mysqli_error($conn);
}

mysqli_close($conn);


?>

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?

I hard code it and added a thousand more rows

basic syntax

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

$tmp contains the difference between the current time and the start time, when this line is executed:

$tmp = microtime(true) - $iStart;

So, do you want the time for each individual query to execute, or the time for them all to execute, or the cumulative time each time a query is run?

I would like the time for all to execute so soon as you type in say

Name - Jim
Email - jim@hotmail.com
Website - google.com

It will insert that value 1000 times once the submit button has been clicked

An overall time for all as one result … example id like to see is something show like;

Time to execute 1000 rows = 32.5 seconds

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

I’m wondering if you should try an EXPLAIN for your query?
https://dev.mysql.com/doc/refman/5.7/en/explain.html

I have now followed what you guys have said and now get the following results

1 INSERT -
0.0069141387939453

10 INSERTS -
0.036954879760742

100 INSERTS -
2.4831295013428

1000 INSERTS -
411.93199157715

Does that look right to you? all of the above is shown in seconds not milliseconds

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.

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.