Symbolic Links

Performance is often at odds with security. One security threat comes in the form of symbolic links. Although symbolic links simplify administration, you need to be careful about any potential problems.

When an application such as Apache tries to read a file, the work is done by a set of libraries provided by the operating system. The application normally is not aware of whether the file is a real file or a symbolic link. To prevent Apache from inadvertently accessing locations that it shouldn't, the system normally will not follow symbolic links. However, in some cases you might want to follow symbolic links, so you are provided two options – FollowSymlinks and SymlinksIfOwnerMatch – either of which can be set in any Options directive.

As the names imply, FollowSymlinks tells Apache to following the symbolic links it encounters, whereas SymlinksIfOwnerMatch says only follow them if the owner of the source and target are the same.

Loss of performance comes when neither FollowSymlinks or SymlinksIfOwnerMatch are used. Before opening the target file, Apache needs to check whether any of the elements in the path are symbolic links. If so, access is denied. If FollowSymlinks is enabled, this check is not done, and file access is a little bit faster. In the case of SymlinksIfOwnerMatch, an additional check still needs to ensure that the user ID matches in every case. Even if you don't use symbolic links, it is worthwhile to include FollowSymlinks to give yourself a little performance boost.


Most of the web servers I have worked with have been virtual domains of one type or another. Sometimes I have complete root access and can configure things as I see fit. In other cases, I am one of dozens of other domains on a single machine, so the webmasters aren't given full access. To simplify configuration, Apache systems that don't provide the webmaster with full access are often configured to let the webmaster make changes through the .htaccess file in the project directory. Unlike changes made directly in the server or virtual host configuration, changes made to .htaccess are active the very next time the server tries to access something underneath the specified directory. To enable this feature, you need to turn on the AllowOverride option.

By default, Apache checks for a file named .htaccess. (The name of this file is configurable with the AccessFileName directive, but I have never seen a system that used a different name.)

Before serving the files in a directory, Apache will first look for .htaccess if AllowOverride is enabled. This check takes time and is wasteful if you will never have any .htaccess files. To make matters worse, Apache checks in all of the parent directories for .htaccess. Depending on where the file for the web server resides (DocumentRoot), this could be several layers deep.

Typically you don't access files outside of DocumentRoot, so for the directories above it and for files without different options, you can give yourself a performance boost by setting AllowOverride to None. One configuration I often use enables override for the DocumentRoot file of each virtual host – in that the root directory almost always has a .htaccess file – but then disables it for subdirectories.

Faster Pages

Increasing web server performance is only part of the battle. If your pages are improperly designed, making changes to the server configuration could have little or no effect. For example, if you have lots of high-resolution, 5MB images on your site, you can do little to configure your web server to compensate effectively for the performance loss you'll suffer serving up these big files. If each time a page is loaded it needs to load multiple CSS or JavaScript files, you should address this problem before you start tweaking the web server. By combining pages to reduce the number of HTTP requests, you can often decrease the overall load time and give the server the chance to service other visitors.

Another technique that speeds your pages (by decreasing the number of file accesses) includes CSS or JavaScript directly in the HTML file (or in the rendered HTML). Note that you are not gaining anything by rendering the HTML with something like PHP, which loads the CSS or JavaScript from another file, meaning you still have multiple file accesses.

Small changes, like removing unnecessary HTML tags or CSS class definitions, decrease file size, allowing files to load quicker so the page displays faster. It might not be visible to individual visitors, but the performance increase benefits the web in terms of less time spent processing the request, plus the decreased need for serving the same number of pages.


With the vmstat command, you can monitor how much time is spend waiting for I/O. If you look at the wa column in Figure 2, you see the percentage of time spent waiting for I/O.

If this waiting time remains low while your web server is under heavy load, you don't necessarily have a problem. On the other hand, if you use a tool like awstats to show access statistics, you can get an idea of the average number of files read for each page rendered.

To increase the likelihood that files will be cached, use page expiration. If you use the default, files might be retrieved even when they don't really need to be. However, by increasing the expiry on your pages, you ensure that the page can be cached for a longer period (either by the browser or a proxy).

To do this, you need mod_expire, which is fairly common in many Linux distributions. Of the different directives, ExpiresActive can be included with the server configuration, virtual hosts, directory blocks, and .htaccess files. If included, it applies only to that particular part of your site. For example, you could enable it for the entire site then turn it off for a specific directory by including it in a .htaccess file. The ExpiresDefault directive specifies the default expiration, and you can specify dates on the basis of the date the file was last modified or accessed. Because you can specify the date in a human-readable form,

ExpiresDefault "modification plus 1 week"

would set the expiration date to one week after the file was last modified.

Taking this a step further, the ExpiresByType directive lets you specify an expiration on the basis of MIME type. For example, images typically have a longer expiry than HTML files.

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Optimizing Servers

    Your homepage was just linked by Slashdot, a new email campaign goes out tonight, and you need the database to deliver survey results. We’ll show you how to help your servers survive the strain.

  • Mod_Mono

    Mod_Mono lets you host .NET applications on your Linux Apache 2 server.

  • Light Web Server Alternatives

    Apache has ruled the web since the mid-90s, but not all users are happy with it. Recent competitors Cherokee and Lighttpd offer an uncomplicated alternative for users who are looking for something light.

  • Apache HTTP Server 2.4

    Apache HTTP Server version 2.4 is full of exciting new features. We share a few of them with you.

  • Magic URL

    With a highly secure Linux server, you don't need a fixed IP address to connect over a cellphone network from anywhere on the planet if you have a Magic URL.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More