Slow echo(...), mysql_close() or ...?

Hi,

Every so often I get a report that a page takes a while to load.
The script itself takes a while to run.
So I added a bit of logging all over the place and I have narrowed it down to the echo(...) or the mysql_close() at the very end of my script.

What I do is build the whole page in a string variable and echo it at the end. The page is not that big really.
I do about 10 SQL queries, (INSERT/SELECT/UPDATES), and nothing really time consuming.
In fact, after timing it, building the page itself takes less than a second.

Then I call 'echo($my_variable)' and 'mysql_close()' and then I take a final time check of how long the page took to load.

Now, either the echo(...), the mysql_close() is slow. They sometime take over 10 seconds, (and in rare cases, even longer).

What do you thing the problem could be? And I can I trace it further to find who is at
fault?

How can either of those functions be so time consuming?

Any sugestions?

FFMG

 

Try to get elapsed time once again using this method:

<?php
$time_start = microtime(true);

-----
your code snippet to test

-----

$time_end = microtime(true);
$time = $time_end - $time_start;
?>

Code (markup):

 

Close the DB connection first then do the echo and see if that solves your problem. There is a bug about this noted in the vBulletin forum code I have come across.

 

Thanks for that, but that is how I narrowed it down in the first place.

Now I need to know why Mysql_close() or echo() would be slow.

FFMG

 

Thanks, I will try that.

You wouldn't have the link with you off-hand?
I am just curious to see what the problem might be.

FFMG

 

No, saw it in some source code. Couldn't even say which file at this point.

I have changed my source code on several apps to do this and it seems to have helped in that there are no mysql connections left open and speed is not an issue anywhere that I'm aware of.

It's such a simple change too.

 

Why would you want to capture the entire output as a string? Whatever your motivation I'm sure there are more robust solutions such as output buffering.

PHP is design to easily parse inline code with HTML.

This is wrong:

	$string = '';
	for($i=0; $i<= 20; $i++){
		$string .= '<div>I am currently on the '.$i.' loop</div>';
	}
	echo $string;

PHP:

This is correct:

<?php	for($i=0; $i<= 20; $i++){ ?>
	<div>I am currently on the <?php echo $i; ?> loop</div>
<?php	} ?>

PHP:

I concede the example given is rather basic and may only provide marginal performance improvement however if you are constructing your entire output as a string it will be an order of magnitude better.

Bobby

 

You are probably correct, but my site is a blog hosting site, (see my sig), and I need the entire page to parse out all the bad code that they often throw at me , (I am fast becoming a security expert when it comes to code injection).

I have managed to clean it all down to about 1 second per page, but the echo(...), (or mysql_close()), seem to slow the whole thing down quite a bit.

Because at first I thought it was my code I spent quite a bit of time optimizing everything, only to realize that sometimes, the echo(...), (or mysql_close()), add 10 to 20 seconds.

FFMG

 

Understood...that is the primary reason that most create one big string for their script output. However, you could use something like this:

	ob_start();
	
	// business logic of the script
	
	$output = ob_get_clean();	
	// Run it through a sanitizer function
	sanitize(&$output);
	
	echo $output;

PHP:

Bobby

 

You must pass variables like that,

  sanitize($output);

PHP:

And I am really not sure that ob_start(); would make it that much faster.

FFMG

 

I must pass variables by reference? I'm not following this comment...can you elaborate a bit?

If you are not sure why not benchmark the difference between the two? The best way to MAKE SURE is to benchmark and compare.

Bobby

 

The way to pass by reference is

function myfunction( &$var ){
  // ...
}

// and you call it 
$somevar = 200;
myfunction( $var );
// not myfunction( &$var );

PHP:

FFMG

 

You caught me...call time pass by reference is now deprecated as you have pointed out. However, that does not negate the overall point that your current implementation utilizes at least twice as much system resources as it should.

Does this little bit of performance optimization matter on sites with small traffic volumes? IMO, it always matters...however your mileage may vary.

Bobby