<VirtualHost 123.123.123.123:80>
  ServerName example.org:80
  ...
  DocumentRoot /home/example.org/public_html
  <Directory /home/example.org/public_html>
    AllowOverride All
    ...
  </Directory>
  ...
</VirtualHost>

In order to prevent the htaccess lookups on the filesystem without losing the htaccess functionality – at least at the DocumentRoot level- I transformed the configuration to the following:

<VirtualHost 123.123.123.123:80>
  ServerName example.org:80
  ...
  DocumentRoot /home/example.org/public_html
  <Directory /home/example.org/public_html>
    AllowOverride None
    Include /home/example.org/public_html/.htaccess
    ...
  </Directory>
  ...
</VirtualHost>

Let’s see what we have accomplished with this:

1. httpd does not waste any time looking for and parsing htaccess files resulting in faster request processing,
2. the virtual host administrator can still override the configuration options of the document root manually or through the web interface of the web application.

Seems like a win-win situation performance and functionality wise.

But, as usual, there is no win-win situation without a downside. In this case, the above trick weakens the server’s security. Let’s see how.

Although the configuration of a directory can be set in both httpd.conf and the directory’s htaccess file, not all directives can be used in both contexts. htaccess files support a subset of the directives that can be used in the Directory context within httpd.conf. By including the htaccess file in httpd’s configuration the vhost admin is no longer restricted to that subset of directives.

This means that by implementing the above configuration the virtual host administrator is granted more privileges regarding the configuration of the virtual host. This also means that a potential attacker, that would exploit a vulnerability of the web application, would be granted the same privileges once he got write access to that htaccess file.

So, although this trick may seem like a good idea at first, it is in fact a rather bad idea and should never be used in production, unless you trust the virtual host administrator and the web application. I do not intend to use such a configuration and I do not recommend it. There are by far better ways to speed up Apache.

Your comments and suggestions are welcome.

Related Articles

• .htaccess Cheat Sheet
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• Use mod_deflate to Compress Web Content delivered by Apache
• Script for Apache Error Report
• Using the mod_dav_svn SVNParentPath directive with multiple authz files

For instance, my virtual CentOS server GRUB configuration has the following entry:

title CentOS (2.6.18-164.6.1.el5)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-164.6.1.el5 ro root=/dev/VGSERVER/LVROOT divider=10 clocksource=acpi_pm
    initrd /initrd-2.6.18-164.6.1.el5.img

The divider option adjusts the kernel’s internal clock by dividing its default frequency by 10. So, my kernel is now clocked at: 1000Hz / 10 = 100Hz. Well, that’s not optimal, but suits my current needs. Until CentOS/RHEL 5.3, this option also served as a workaround for time synchronization between the host and the guest OS. For CentOS 5.4 and later, we just need the “divider” in order to underclock the kernel without actually recompiling it. Also, the “clocksource” option is not required any more.

You can find information about whether the divider option is supported by your distribution by checking the Timekeeping best practices for Linux guests article on the VMware knowledge base.

But, make no mistake. All the above are just a workaround. The kernel configuration includes the option to configure it as “tickless” (CONFIG_TICK_ONESHOT & CONFIG_NO_HZ):

Processor type and features ---> [*] Tickless System (Dynamic Ticks)

From the kernel docs:

This option enables a tickless system: timer interrupts only trigger on an as-needed basis both when the system is busy and when the system is idle.

This sounds like a Real Solution™. I tried to build a minimal kernel (version 2.6.32), using the “tickless” feature, specifically for Virtualbox, but, after spending many hours with it, I could not make it recognize my root LVM volumes. So, being extremely frustrated, I abandoned the whole project and used the divider option as I mentioned above.

If anyone has built a minimal custom kernel specifically for Virtualbox or VMware, which supports LVM/RAID and can actually boot a root LVM system, please let me know.

Related Articles

• Howto: Run VMWare on a Physical Windows Partition
• Running supervisor 3 on CentOS 5
• CentOS, Debian, FreeBSD, OpenSolaris
• Awaiting CentOS 6
• Install OpenSolaris in VirtualBox – Screencast

Requirements

Speaking about httpd (Apache), the following modules should be loaded:

LoadModule rewrite_module modules/mod_rewrite.so
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule mime_module modules/mod_mime.so

The modules above are so standard, that there is high probability that they are already loaded.

Installation

• Before installing WP-Super-Cache, make sure you have properly uninstalled any other caching plugin. This step is not covered by this guide. Please, consult each plugin’s documentation.

• Download the plugin (wp-super-cache.X.X.X.zip) and unzip it in your plugins directory, so that you have a directory structure like /wp-content/plugins/wp-super-cache/. Assuming you are in the root directory of your website (DocumentRoot):

cd wp-contents/plugins/
wget http://downloads.wordpress.org/plugin/wp-super-cache.X.X.X.zip
unzip wp-super-cache.X.X.X.zip
rm wp-super-cache.X.X.X.zip

• Make the directory wp-content writeable by the Apache web server. If this is not possible, give write permission to the “world“. Do not worry, this is a temporary modification. Permissions will be reverted after we are finished. To enable write access for the the “world“:

chmod o+w wp-content

• Go to the WordPress plugin administration panel and enable WP Super Cache
• Then, edit wp-config.php and make sure you add the following line anywhere above the “require_once(ABSPATH.'wp-settings.php');” line

define( 'WP_CACHE', true );

• Go to the plugin’s administration panel in WordPress (that will be under the Settings menu) and enable caching (that is in the very first configuration section “WP Super Cache Status“).
• Put the mod_rewrite rules in the .htaccess file located in the root directory of your website. Make sure you paste them above WordPress’ rewrite rules. The plugin guides you in an excellent way for this, so follow the on-screen instructions. There are also some other settings that need to be placed in wp-content/cache/.htaccess, but these should have been created automatically.
• Remove the write permission we had set in a previous step. If you had enabled it for the apache user, then remove it from that user. If you had enabled it for the “world“, do the following:

chmod o-w wp-content

The benefits of using the supercache are that your content is delivered fast and the system resources are not wasted. WP-Super-Cache creates and serves static versions (pure HTML) of your webpages and thus php is utilized less and less SQL queries are sent to your database server (MySQL, PostgreSQL, etc).

At this point, the plugin should have started caching your content as you visit web pages. Sit back and enjoy!

Upgrade WP-Super-Cache

For step-by-step instructions about how to upgrade WP-Super-Cache to newer versions, please read the “How to Upgrade WP-Super-Cache” article.

PS: The use of this plugin also implies that I have stopped using my Fast-Static-Feed plugin, since wp-supercache caches feeds too.

Related Articles

• How to upgrade WP-Super-Cache
• CPU Time saved by WP-Super-Cache
• Fast-Static-Feed WordPress Plugin
• WordPress 2.1
• WordPress Meta Tags plugin stable release

First, is the cipler-none patch that adds none as a valid argument to the -c command line option. By using it, the transferred data is not encrypted. Pros: eliminates the data encryption overhead. Cons: totally insecure method of transferring sensitive data.

cipher-none-patch

Note: the OpenSSH server, even if it has been patched with this code, does not accept unencrypted connections by default. This has to be enabled explicitly in the sshd configuration (sshd_config) by adding the none “cipher” to the list of the accepted ciphers:

Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,none

Note2: here is step-by-step guide how to configure the SSH authentication using public keys.

Second, is a set of patches, created at the Pittsburgh Supercomputing Center, which eliminate the bottlenecks caused by some of the internal buffers that control data flow in network connections through OpenSSH. This project is called High Performance SSH/SCP (aka HPN-SSH). Benchmarks show that even encrypted network connections using HPN-SSH perform extraordinarily better than the usual encrypted OpenSSH connections.

OK, this info exists here for completeness, as those HPN-SSH patches have not been designed for home networks! Possibly it might make no difference if you use the regular OpenSSH or HPN-SSH in your home LAN.

Note: the HPN-SSH patches also contain code that adds the none cipher, similar to the cipher-none patch, so, if you intend to use HPN-SSH, it is not required to apply both on the OpenSSH source.

Finally, apart from all these, if you ever decide to use SSH for networking seriously consider using SSHfs (see also SSHfsFAQ).

Related Articles

• How to configure mod_gnutls to use the RC4 cipher to mitigate the SSL/TLS vulnerability
• Assign Virtual IPs to your NIC
• Setup the SSH server to use keys for authentication
• Encrypt devices using dm-crypt and LUKS
• TrueCrypt on 2.6.18 kernels

Taking these things into consideration, I decided to write Fast-Static-Feed, a plugin that can cache the site’s entries feed, and deliver a static XML file instead of constantly generating the feed content on every client request. This, combined with the fact that the web server can compress the web content on-the-fly, has greatly reduced the waste of bandwidth and system resources.

How it works

Fast-Static-Feed performs the following actions:

• Every time a post is published or an already published post is edited, the plugin dumps the entries feed (that is the feed of the blog posts) to a file. This way, the static XML file is always contains the most fresh content of your blog.
• Every time a feed is requested, instead of re-generating the XML content over and over, this plugin delivers the static XML file. This is completely transparent to the client as there are no HTTP redirects involved. Your content is just being delivered faster!
• If the plugin is enabled, but the static files have not been created yet, the plugin will try to generate them automatically. Upon failure to do so, a 404 Not Found HTTP error code will be returned to the client.
• It also checks if the client’s request includes the If-Modified-Since HTTP header and, in such a case, it checks the static file’s modification time. If the client’s cache is current, it just returns a 304 Not Modified status to further reduce bandwidth usage.

The plugin caches all four types of feeds WordPress supports -RSS 2.0, Atom 1.0, RDF, RSS 0.92-.

Only the feeds that contain your blog posts are cached. The comments feed, each individual post’s comments feed, feeds for categories, tags, authors etc are still generated dynamically every time they are requested.

This plugin does not interefere in any way with the generation of rewrite rules and the generation of your site’s feed links.

Configuration

Generally, the plugin does not require any configuration in order to work.

One mandatory prerequisite is that the wp-content/ directory is writable by the web server. If it is not, the plugin will not be able to create the static files and, consequently, the clients who request a feed will receive a 404 Not Found HTTP code.

Furthermore, there are two options within the source code fast-static-feed.php that can be set.

// By default, the WordPress feeds contain elements of the 'wfw' namespace
// (CommentAPI), so a feed reader can fetch each feed entry's comments.
// By setting the following to 1, these elements will be stripped
// from the static feed.
// It is recommended to set this to 1 in order to save bandwidth.
// More info: http://wellformedweb.org/news/wfw_namespace_elements/
$FSF_STRIP_COMMENTS = 0;
// Set the following to 1 and various messages will be recorded in the logfile,
// which is located in the cache dir (wp-content/cache-xml/)
$FSF_DEBUG = 0;

It has already been mentioned, but it is important to note it again: The only mandatory prerequisite is that wp-content/ is writable by the webserver.

Installation

Make any changes to the configuration options within fast-static-feed.php and upload the file to wp-content/plugins/ directory. Then, activate the plugin through the WordPress administration panel.

License

Fast-Static-Feed is an open-source project, released as Free Software under the terms of the Apache License version 2.

Downloads, Issue Tracking, Support

For the latest releases of Fast-Static-Feed please visit the downloads section of the Fast-Static-Feed Development Portal.

The development website also hosts an issue tracking facility, where you can submit your feature requests or report bugs, and discussion boards, where you can get first class support from the community of users.

Donate

This plugin is released as free software. Nevertheless, its development requires time and effort. A small donation, as a sign of appreciation of the effort, is welcome. Please, use the following button to visit the Donations page. Thanks in advance for your support!

Related Articles

• More-Feed-Excerpt WordPress Plugin
• Bot-Allow-Content WordPress plugin
• How to enable WP-Super-Cache in WordPress
• Add-Meta-Tags WordPress Plugin
• My-Tags WordPress Plugin

Introducing mod_deflate

Apache prepares the response that will be sent back to the client in several stages. One of those stages involves the modification or conversion of the data using output filters. mod_deflate, once loaded and activated, inserts such a filter, named DEFLATE, in Apache’s chain of output filters, which compresses all data that goes through it according to some rules the web server administator has defined. For instance, one can set the compression level, restrict the compression to particular MIME types or prevent some problematic web browsers or other HTTP clients from receiving compressed data from the server.

mod_deflate also offers an input filter which can be used to decompress compressed HTTP requests, but this feature is outside of the scope of the current document.

Here follow some instructions on how to configure mod_deflate. Most of it can be found inside HTTPd’s official documentation, so you’d better read this resource as well.

Note that all of the following configuration directives can be inserted in Apache’s main server context or can be saved to a file that will be loaded from within the main server or any other virtual host context. If the configuration directives are inserted in the main server context, then they will be inherited by all virtual hosts.

Load mod_deflate

mod_deflate can be loaded like any other Apache module:

LoadModule deflate_module modules/mod_deflate.so

Please note that this directive can only exist in the main server configuration.

Enable Compression

The compression of the data can be enabled for all data that goes through the DEFLATE filter or selectively depending on its MIME type.

To enable the compression for any type of content, insert the following directive:

 SetOutputFilter DEFLATE

Alternatively, to define which filetypes should pass through the DEFLATE output filter use the AddOutputFilterByType directive. The following is an example:

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

Set the Compression Level

Generally, the deflate compression algorithm is fast enough, so setting the compression level to the maximum (9) will not cause any noticeable trouble, even to relatively old hardware.

DeflateCompressionLevel 9

Custom Rules for problematic browsers

The compression can be turned-off or be restricted to files of type text/html for known problematic web browsers. These are taken from the official documentation.

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Keep track of the compression

Finally you can keep track of the compression in order to evaluate the effectiveness of the use of mod_deflate in your server.

The following directives define some variables, such as:

• instream : the size in bytes of the data as received by the DEFLATE filter.
• outstream : the size in bytes of the compressed data as returned from the DEFLATE filter.
• ratio : the compression ratio, (Output/Input)x100

DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio

Finally, you can define a custom logformat so to be able to record the aforementioned values to a logfile:

LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate

The deflate logformat can be used for the main server’s or for any vhost;s logfile.

Effectiveness of Compression

It is well known that not all document types can benefit the same from compression. Generally, the deflate algorithm can compress text surprisingly fast and with a very high efficiency ratio. On the other hand, it is almost useless when used to compress images which have been prepared for the web such as PNG, JPEG, GIF and generally all other image types in which the data has already been compressed. The same goes for compressed audio files, such as MP3, AAC, OGG, videos, PDF documents and all other already compressed files.

So, the benefits of using mod_deflate to reduce the bandwidth usage and speed up the content delivery are heavily dependent on the type of files your web server delivers.

Browser Support

A web server that sends compressed data to clients would be completely useless if the HTTP clients couldn’t decompress that data. All modern and popular web browsers support accepting content that has been compressed using the gzip or deflate algorithms, so there should be no problem at all.

Appendix I

Here is the complete mod_deflate configuration as described in this article. Save it in a file, named deflate.conf and import it in the main server’s configuration using the Include directive

(Include /path/to/deflate.conf):

#
# mod_deflate configuration
#
LoadModule deflate_module modules/mod_deflate.so
<IfModule mod_deflate.c>
        AddOutputFilterByType DEFLATE text/plain
        AddOutputFilterByType DEFLATE text/html
        AddOutputFilterByType DEFLATE text/xml
        AddOutputFilterByType DEFLATE text/css
        AddOutputFilterByType DEFLATE application/xml
        AddOutputFilterByType DEFLATE application/xhtml+xml
        AddOutputFilterByType DEFLATE application/rss+xml
        AddOutputFilterByType DEFLATE application/javascript
        AddOutputFilterByType DEFLATE application/x-javascript
        DeflateCompressionLevel 9
        BrowserMatch ^Mozilla/4 gzip-only-text/html
        BrowserMatch ^Mozilla/4\.0[678] no-gzip
        BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
        DeflateFilterNote Input instream
        DeflateFilterNote Output outstream
        DeflateFilterNote Ratio ratio
        LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
</IfModule>

This configuration will be inherited by all virtual hosts.

To disable it just comment out the line that loads the mod_deflate module (#LoadModule ...).

To record mod_deflate‘s specific variable (instream, outstream, ratio) values for a virtual host, just add a new log file of type deflate:

CustomLog /path/to/vhost/logs/deflate_log deflate

This will give you an idea of how efficient is the use of mod_deflate in that particular vhost.

Related Articles

• Optimize and Compress CSS Files
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• Script for Apache Error Report
• Speed up Apache by including htaccess files into httpd.conf
• Check Server HTTP Headers with CURL

Before proceeding, make sure you have backed up your current non-optimized style-sheet. CSSTidy will not touch your original file, but taking some precautions is a good habit.

Launch csstidy without arguments for a rather short description of the command line switches:

csstidy

Although it is possible to define each parameter individually, some pre-defined templates are what you will most probably use. These include: low|high|highest. The higher the optimization level, the smaller the CSS filesize. More on templates here.

I tried the high and highest templates. The latter produces a style sheet that contains all code in a single line, but that file would not validate, so I used the high template:

csstidy style.css --template=high style.css.out

The compression ratio for my file was 34.86% which was quite satisfactory. Also, the final file validated properly.

CSSTidy does a good job either you want to optimize the stylesheet for readability or for filesize. On the other hand, the CLI interface does not provide enough information about each of the CLI switches. They are pretty self-explanatory, but I guess a little description for each one of them wouldn’t hurt anyone. Also, I could not make the “--remove_last_;” option to work.

The only difference I could notice in my stylesheets between the high and the highest templates was that the whole code was squeezed in a single line when highest was used. Probably, this template performs some more optimizations than just deleting the line-feed characters, but it seems that there was nothing else that could be optimized in my CSS file.

Apart from this command line utility, there are also a lot of online CSS optimizers. I didn’t have the time to try them all, but I think I can recommend the following:

• Clean CSS – this seems to be the PHP version of CSSTidy. Everything seems to work as expected and the results are the same as before.
• Icey CSS Compressor – This is another web-based CSS optimizer which performs very well. By using the default settings you get a single line with highly optimized CSS code. The compression ratio is similar to CSSTidy’s. In order to separate each selector with a line-feed character, so that the final CSS validates, you can pass the optimized CSS through sed:

  sed -i 's/}/}\n/g' style.css.out

If anyone knows about any other utility I would be very glad to know about.

Related Articles

• Use mod_deflate to Compress Web Content delivered by Apache
• VeriTAR – Verify checksums of files within a TAR archive
• How to annotate PDF files in Linux using Xournal
• Creative-Commons-Configurator WordPress Plugin
• WordPress 2.2.1 bugs

Information about its usage can be found inside the script. It is completely unsupported and it will not be further developed.

Special Note: My script visits the blog 60 times/hour, so do not run it on a production blog, unless you have adjusted your web server statistics analysis software to ignore those visits.

Related Articles

• Fast-Static-Feed WordPress Plugin
• Creative-Commons-Configurator WordPress Plugin
• WordPress 2.5 – Plugin Compatibility
• More-Feed-Excerpt WordPress Plugin
• Bot-Allow-Content WordPress plugin