When a web request comes into to your web server, the kernel accepts the request, does a context switch and hands the request to the Apache process which runs in usermode. This context switch takes a miniscule amount of time, however, consider one million requests for images and content for images, and that little bit of time for each request adds up very quickly.

Tux is a kernel mode content accelerator. Any static content is served by Tux without a context switch. On a page that contains 25+ graphic images and one php script, this amounts to quite a savings. However, Tux is simple and can only handle static content. Requests that Tux cannot handle are handed to a backend web server. In our case, we're using Apache as the backend for anything that Tux cannot handle.

Apache is designed for stability and versatility and performance is a secondary concern. While Apache does do well in most hosting environments, in high traffic situations, Apache remains stable, performance is reasonable, but there is room for improvement. The more content that you have that is static, the more Tux will help. If your site is mostly dynamic with few images, Tux may not show measurable results.

While Tux is quite powerful, fast and simple, there are situations that need special attention.

• Password Protected Areas - We can deal with password protected areas by moving things around on the physical disk and telling Apache where they are. This will affect paths for any scripts which use the real physical path of files.
• Hotlinking - The system can either allow or deny hotlinking. Tux checks to see if the referrer is from the local site. If www.domain.com requests an image on domain.com, the request will be honored. If www.otherdomain.com requests an image on domain.com, the request will be denied. This is a serverwide setting and we can select which file types are protected. Either all domains are hotlink protected, or no domains are hotlink protected. For those of you allowing people to hotlink banners, buttons, and images that don't want to allow global hotlinking, we can create subdirectories in your web area that can be hotlinked. Similar to the Password Protected area, we would set up a directory in your web area that was referenced by a different path to the outside world. In your FTP account, it would look something like: domain.com/hotlinkablecontent and the web url might be domain.com/banners.
• Overlaid domains - If you have multiple domains hitting one actual domain, we need to create symlinks to allow tux to serve the content for each domain.
• Wildcarded domains - If you have taken advantage of wildcarded domains that do NOT have a physical presence, Tux doesn't handle this currently. An example of this might be if you have a site of domain.com, and have used keyword.domain.com for Search Engine positioning. If you have an actual site at keyword.domain.com that is NOT served by the site on your system at domain.com, then you aren't subject to this problem. If you use wildcarded domains, we should have a solution for this shortly.
• Parsing of .html pages - If you currently parse .html pages for php or SSI, we need to know this so that we can alter the way tux behaves for .html pages.

First, make a note of anything that might need to be addressed. We can do a search and replace and adjust paths, but you'll still need to do a runthrough to make sure we addressed everything. By having the list, we know what to look for and you know what to doublecheck after the conversion.

Second, we'll need to coordinate a Tuesday or Wednesday to do the conversion. These are the lightest days in terms of our workload and the lowest traffic days. While the actual conversion requires preparation on both sides, typically, its a few hours of preprep work to make sure things are still working properly under Apache, then we flip the switch. About five minutes later, Tux is running with Apache as the backend, and then its time to go through your checklist to make sure everything that worked before is still working.

The process is not a complex one, but it is tedious. A typical conversion for a dozen domains might take several hours. However, we believe that the conversion is worth it. We're offering a special rate of $25 per domain, or $300 per server to convert your server to use Tux.

This is not to say that Tux & Apache are the only choices for use on your server. Talk with us about other options including Boa, thttpd, and AOLServer. Depending on your web sites and the type of traffic you have, we can choose web servers that more closely match the type of traffic you have on your web sites.