Q1: Does ifmodule mod_php4.c suggest that its for PHP 4 and not PHP5?
Yes. RUN. PHP4 has no reason to still be installed unless you have scripts that will break under PHP5.
Q2: Would it be faster for the server engine to have this in php.ini, instead of htaccess?
It shouldn't matter one iota except for a few opcodes during Apache startup. Meaning, no... unless the .htaccess file was not already present, in which case there may be a tiny performance hit as Apache finds the file. (Fewer .htaccess files => less needless stat calls => faster performance for everything.)
Q3: The compression is default set to 16386. What happens if we lower it to, say, 4K
This is the size of the buffer for the output. If you drop it to 4k, data will be sent slightly sooner. Depending on the average size of the page, this can mean that data could need to be sent in multiple chunks, which may well be a very tiny performance drop for the user getting the data.
Q4: What would happen if we set it higher, e.g. 128K ?
This means that 128k of buffering woudl happen before data was sent to the client. If your pages are over 128k post-gzipping, something's probably wrong.
setting up PHP bandwith savings and the effective speed gain experienced:
A while ago, people started recommending not using PHP's built-in gzip, suggesting Apache's mod_deflate instead. This lets PHP just care about generating the HTML, and lets Apache worry about compressing and serving it. It also has the same effect. While the manual page for mod_deflate is encyclopedic, it's also simple and straightforward. You may already have it available and simply have the required lines unused in your httpd.conf.
Because it can operate at the "filter" level, using it also means that anything producing the compressed MIME types, including CGI scripts and plain old HTML files can get gzipped automatically.
Update with answers to comments:
Do I read on & inbetween the lines correctly that you suggest me to remove the block A and have only block B in place as seen here
This is generally correct, though the configuration block you have there is currently targeting files by extension. Instead, you can target by MIME type using the AddOutputFilterByType configuration directive, as documented on the mod_deflate manual.
When removing the PHP configuration, also inspect the php.ini on your system, as it may also contain compression directives that you might not need.
Apache will be smart enough not to double-gzip content, no matter what method you use to turn on mod_deflate.
what would be the proper way to change the block A to make it most compatible with PHP5?
It depends on what the 5.x version of mod_php is called on your system. It'll be either just plain old regular mod_php or mod_php5. Look for the LoadModule directive elsewhere in httpd.conf (or in /etc/httpd/conf.d/*.conf).
The actual configuration directive is correct, it's just wrapped in a "do this only if PHP4 is loaded" block.
Let's say that your 5.x mod_php is called mod_not_butter. If this is the case, the block would look like:
<IfModule mod_not_butter.c>
php_value suckitude_factor -1
</IfModule>
I wonder what other options I might have to customize/speed up my mod_deflate APACHE gzip processing
There are lots of options. Don't touch any of them except the buffer size (DeflateBufferSize), which you should set to the average uncompressed data size that you expect. (I earlier misremembered that the buffer was after compression, while it's actually before.)
All of the other options are sane defaults that you don't need to touch, because by the time that changing them would actually impact performance in a meaningful way, you'll want to have other technologies involved to take load off Apache.
