Php/mysql Benchmarking Tips

[section31]

Does anyone have any tips on benchmarking php/mysql scripts. The best idea I found was to make my own linux/apache/mysql/php server and run that ab utility... Is the best and only way? Timer scripts are only good to test speed, not so much for efficiency.

 

Found the info about in this article. http://www.phplens.com/lens/php-book/optim...bugging-php.php

Edited May 21, 2005 by section31

[TweezerMan]

I don't really have any experience with this, but it seems to me that you would need to benchmark scripts on your own server. One reason is access - some of the things you should be looking at aren't available to you on a shared server (no SSH access and no root access, for example). Also, some benchmark tests involve stress tests on a server - this is something that really can't be allowed on a shared server. If you're stressing the server, you're making the server unusable for every other user on that server.

[borfast]

If you can spend the money, get Zend Studio and test the scripts on your computer. It has a PHP profiler and a debugger which are well worth the price on their own.

[section31]

thanks, i'll check out the trial version.

[section31]

hey raul, so i installed that trial version of zend studio and i'm looking at the profiler right now. It doesn't look like it does stuff thats comparable to ab. Run a script an X number of times on an X number concurrent connections while monitoring the servers resources. Now that I have apache installed on my windows box..I wonder if there is a way I can use ab on windows.

Edited May 22, 2005 by section31

[borfast]

Well, I don't know ab so I'm not able to help more

[section31]

Just an update.

 

I just finished testing out some of my scripts using ab, the apache benchmark utility and while i was running ab I would run top on the server to check memory usage and cpu utilization. Suffice it to say, i was unable to determine if one particular script was more efficient than the other. The results were varying too much. However, just using ab for execution times did give me something to start thinking about. For example this code, which would you think would be more efficient.

 

>// ############## Which is more efficient ####################

// ############## USING echo and keeping the data in the buffer ####################
ob_start();

for($i=0; $i<1000; $i++) {
echo 'Very long STring';
}
$test = ob_get_contents();
ob_end_clean();

// Misc Code here

echo $test;


// ############## OR just storing this in a variable ####################

$a = null;
for($i=0; $i<1000; $i++) {
$a .= 'Very long STring';
}

// Misc Code here

echo $a;

 

Using ob_start ended up being faster, yet I thought they would be the same. Don't they both use the same amount of resources, so why is the one using ob_start running faster?

 

 

Here is the same benchark run only once.

http://section31.us/scripts/bench.php

Source: http://section31.us/scripts/bench.phps

 

Oh, and if you're asking yourself how much faster. on ab, i ran 100 requests, with 10 connections, and it comes out to 15-20% faster. This is really sad considering i've been using the other way for the whole year and a half i've been using php.

Edited May 24, 2005 by section31

[TweezerMan]

Using ob_start ended up being faster, yet I thought they would be the same.  Don't they both use the same amount of resources, so why is the one using ob_start running faster? 

<{POST_SNAPBACK}>

I found this explanation for why ob_start is faster than accumulating output text in a variable:

The fastest way to concatenate multiple small strings into one large string is to create an output buffer (ob_start) and to echo into the buffer. At the end get the contents using ob_get_contents. This works because memory allocation is normally the killer in string concatenation, and output buffering allocates a large 40K initial buffer that grows in 10K chunks.

Basically, PHP has to reallocate the variable's memory every time you add text to it, while the output buffer's memory is allocated in chunks (40K at first, then is increased in 10K increments as needed). Fewer memory reallocations = faster code.

[section31]

Wow, thats what i get for not reading that article entirely. Makes sense now.

[section31]

In case anyone is actually interested in this stuff, I'm going to continue my own debate on this issue.l

 

I think i might have made a mistake on my previous code. Granted that article explicitely states that using obstart is faster than concatenating multiple small strings but now my benchmarks contradict that.

 

http://section31.us/scripts/benchmarks/bench.php

http://section31.us/scripts/benchmarks/bench.phps

 

For some reason on the code I used before, the string i used wasn't the same length....lol

 

I've tested both of these using ab and have confirmed the results. Now i'm really confused, just when I thought it was all becoming clear to me.

Edited June 1, 2005 by section31

[surefire]

If you're looking to make your queries run faster, then consider testing them in phpMyAdmin under the SQL tab and clicking 'Explain SQL' after running the query. Look at the number of rows returned and try to reduce that number by using ANSI style joins.

 

Do a search on 'ANSI joins' if that terms is unfamiliar. Lots of great free tutorials on it.

 

If you can reduce the number of queries and the size of the results returned, your pages will run much faster and the drain on resources will go down by quite a bit.

Edited June 1, 2005 by surefire

[TweezerMan]

I can't explain what you're seeing, but here's a few things to consider:

 

1) Your code is supposed to be testing "concatenating multiple small strings", but the string you are concatenating over and over is about 6K in size - not exactly what I would consider to be a small string. As the string size approaches the size of memory that the buffer allocates (10K?), I would expect less of an advantage in using the output buffer.

 

Rather than test 1000 concatenations of a 6K string, I'd probably be testing with a 600 byte string, or even a 60 byte string.

 

2) I was under the impression that you'd only want to use the output buffer in the context of actually outputting something to the browser. If you aren't wanting to output the resulting string to the browser, I'd probably wouldn't use output buffering - I'd just concatenate text into a variable like you do in your first test. I think the overhead of using the output buffer may be too much if you're not going to actually output the buffer contents to the browser.

 

3) I don't think you're testing quite the same thing in each test:

 

In your first test, the sample text is merely concatenated into a variable, then the variable is unset (discarding the text) at the end of the test.

 

In your second test, the sample text is being concatenated into the buffer, but then ob_get_contents() copies the buffer into the $test variable, ob_end_clean() purges the buffer, and finally the $test variable is unset. At the point where the buffer is copied to the $test variable using ob_get_contents(), the text in the buffer is about 6MB in size. I think that would take a measurable amount of time to copy then purge from the output buffer.

 

Basically, you may be comparing apple and oranges and thus not conducting a fair test.

 

I don't know how much this will help, but there's my two cents!

[section31]

thanks for the reply david. Yeah, I don't think i'll ever be using ob_start again for storing stuff to a variable for later use. Its just I've come across all these contradicting sites doing things different ways that claim to be more efficient and I have this urge to find the most appropriate way of doing something. I don't really like just taking their word for it, so I benchmark it myself.