If you are running a web site resource usage and performance can play a big part in your site visitors experience, namely their experience in how long it takes your web site’s pages to load. There are modules called GZip and mod_deflate for Apache web servers that will compress the data requested by a web browser using Zip compression to create a compress stream that is decompressed at the browsers end. This is server wide and effects all web services on the server. The result is less data sent from the server to the browser. This has two huge affects one, it can reduce bandwidth usage by as much as 75% and two, decrease page load times by a factor of 4. Here is some data on this BLOG:

URL: http://mbrando.com

File Size Comparison (in bytes):
Original size: 61964 bytes
Compressed size: 19077 bytes
Savings: 42887 bytes
Percentage saved by
Transfer speed
3.2 X

Dial-up Modem 56.0 Kbps – 8.645s vs. 2.661s
DSL/Cable Modem 256.0 Kbps – 1.891s vs. 0.582s

( Above data by: port80software.com )

Here are some links with additional information

GZip works with Apache 1.3x and Apache 2.x.
GZip Site Home
Compressing Web Output Using mod_gzip for Apache 1.3.x and 2.0.x

Apache 2.x comes with a module called mod_deflate.
Apahce 2.x documentation
Compressing Web Content with mod_gzip and mod_deflate



I run a few cPanel servers and run Munin as my resource monitor. At the time I wrote this the version included with cPanel was munin 1.24. Ever since I have installed the plugin from cPanel it would monitor MySQL upon first install and then stop if the server was reboot. Uninstalling and reinstalling would once again get Munin to monitor MySQL but having to uninstall and reinstall just for a reboot, just did not seem like something that you should have to do. After many months of on and off testing this is the fix I have come up with.

  1. Create a MySQL user with a password that is NOT granted privilege to any DB. Simply create the user.
  2. Create a file called /etc/munin/plugin-conf.d/munin-node
  3. In the file /etc/munin/plugin-conf.d/munin-node put this:
    user root
    group wheel
    env.mysqladmin /usr/bin/mysqladmin
    env.mysqlopts -u [MySQL_usr] -p[MySQL_usrpassword]
  4. Then Save. Where [MySQL_usr] is a valid MySQL user and [MySQL_usrpassword] is it’s password. Note that there is NO space between -p and the password. This is critical.

Now what about 30 minutes to an hour to allow the munin-node to gather enough info to have something to graph. Then go view your Munin graphs. All of your MySQL graphs should have something in them.



I’m sure the internet has changed quite a bit since you first unveiled your web site to the world. The technologies used to build web sites and internet presentations have also changed too. You may be thinking that the time is right to redesign your web site. A new look/ feel and fresh content will go far to better reflect your business services today. Make sure you have someone who understands search engine optimization involved with your project. This is very important for a web site redesign.

In the past it was possible to simply write code to display your pages properly in the few browsers available. Today if your web site enjoys any traffic that comes from the search engines, you want to keep it. This means that your REDESIGNED web site cannot have broken links that come from the search engines or dump all of your old site links to the home page. Doing so will impact your search engine ranking. This will cause your rank to drop. For some business this could have a serious financial impact.

You need to redirect all of your old pages to the new pages that have similar content. Often a web site is transitioned from a static HTML web site to a dynamically scripted web site like those coded with ASP, PHP, .net, Cold Fusion, Java to name a few server side scripting languages. Your old web site may have had links that looked like this:


or something similar. Your new site may simply have restructured how the pages are stored by changing the folder names or your web site is now dynamic. Either way you want your old web page links to be redirected to the new web page links. If you are running apache server you can use an htaccess file in the root of your public folder to preform the redirect of OLD to NEW. This is just one way to make use of htaccess files. Feel free to use your favorite search engine to find other htaccess tutorials for password protected folders or event URL rewriting.

How to use htaccess files with apache server for URL redirect

Create a plain text file named: .htaccess

in the root of your public folder. In this file you will use the following structure to create a redirect that tells the search engines that a permanent change to the old link has been made, meaning the old link is being redirected permanently. The format is action, error code, OLD URL, NEW URL. Each redirect is on its own line like this:

Redirect 301 /your_file_name.html http://www.example.com/index.php?a=12&b=39
Redirect 301 /file_name.htm http://www.example.com/index.php?a=657&b=354&c=234

If your OLD URL happened to have a space, %20, in the file name or folder name put the entire URL in double quotes like this:

Redirect 301 “/folder name/file name.htm” http://www.example.com/content/view/215/27/

This will allow the directive to be performed properly. With out double quote around the URL with a space it can cause an internal error 500 on the server. Often this error is associated with htaccess files the have invalid syntax.


  1. 301 is the error code for a permanent redirect
  2. The OLD URL starts with a forward slash
  3. The NEW URL is a fully qualified URL
  4. The new URL can also be on a different domain too.

That is all there is to it. Save your htaccess file and test it by access an old URL. It should redirect your browser without incident. Using the 301 error tells the search engines to update their index with the new URL.


« Previous PageNext Page »