...making Linux just a little more fun!
By Vinayak Hegde
If you did come to the site to read an article about Tux the Penguin -- the lucky mascot of Linux -- you might be disappointed. But don't go away just yet: read on to find what TUX the webserver can do do for you in terms of performance and you will be delighted. You might just discover something to hack on and tweak. This is an article about TUX - the webserver embedded within the Linux kernel.
The name TUX comes from 'Threaded linUX webserver'. TUX was written by Red Hat and is based on the 2.4 kernel series. It is a kernel-space HTTP subsystem. As you may have guessed by now TUX is released under the GNU GPL. So in the free software tradition, you are free to tweak it and modify it to meet your own specific needs. One of the ways of adapting TUX for our needs ,is by writing TUX modules, which can be user-space or kernel-space modules. The main goal behind writing TUX was to enable high-performance webserving on Linux. This was especially important as Linux is extremely popular in the webserver market.
TUX is not as feature-filled as Apache and has some limitations. But nevertheless, TUX is a complete HTTP/1.1 compliant webserver supporting HTTP/1.1 persistent (keep-alive) connections, pipelining, CGI execution, logging, virtual hosting, various forms of modules, and many other webserver features. TUX is now officially known as the Red Hat Content Accelerator (RHCA).
Though quite some amount of today's webcontent is dynamic generated, most of the webcontent is static. Take for example static webpages and images. This leads to quite a overhead as user-space webservers such as apache have to be use some system calls for actually serving the content. The frequent context switches between kernel-space and user-space programs is quite a performance hit. TUX is a saviour here. TUX can be built into the monolithic kernel or dynamically loaded as a module. The first approach is preferable for servers which are dedicated to webserving. When built as a loadable module, it can be dynamically inserted and removed, as when the service is started or stopped respectively. This approach affords some amount of flexibility.
TUX is used primarily for serving static content, leaving generation and serving of dynamic content to backend webservers such as Apache. Now, newer versions of TUX have the capability to cache dynamic content as well. TUX modules can create "objects" which are stored using the page cache. To respond to a request for dynamic data, a TUX module can send a mix of dynamically-generated data and cached pre-generated objects. Thus, most of the requests which are just "network-copy" operations can be handled efficiently by TUX. The new version of TUX uses zero copy block IO instead of a temporary buffer as in TUX 1.0. Also virtual hosting support has been enhanced for TUX and the number of virtual hosts that can be supported is only limited by disk space and RAM.
Now that we know what TUX is capable of, we can move to installing and configuring TUX. All the information that follows has been tested on Red Hat 7.2 with TUX-2.1.0-2. Due to ease of use and familiarity Apache has been used as the user-space webserving daemon.
Check whether you have tux installed using the command :-
# rpm -q tux
You may get messages similar to the ones below :
# rpm -ivh tux-2.1.0-2.i386.rpm
# patch -p0 < tux2-full-2.4.10 # make oldconfig (enable tux here,recompile and install the kernel)Install the user-space utilities
# tar xzvf tux-2.1.0.tar.gz # cd tux-2.0.25 # make # make install
Create the directory /var/www/html (or some other directory of our choice) and make it the root directory of TUX by changing the value of DOCROOT in /etc/sysconfig/tux. Also you can give the path where your CGI-scripts are stored to CGIROOT. Also the TUXTHREADS variable can be set to an appropriate number here. Also create the index.html page in the root directory. This will be used for testing later.
TUX can be started by using the command. (As superuser)
# service tux start (on RH systems) # ./tux.init start (on non-RH systems) # lsmod Module size Used by tux 75568 0 .... ....Now point your favorite browser to localhost and you should see the index.html page we created earlier. If not something has gone wrong or the configuration is not proper. Check step 8 for details.
# lynx localhost
By default, logging is disabled. To enable logging and referrer logging, give the following commands.
# echo 1 > /proc/sys/net/tux/logging # echo 1 > /proc/sys/net/tux/referer_logging # cat /proc/sys/net/tux/logfile /var/log/tux (this is the default logfile)
For each request, TUX logs the address of the requester, a date and time stamp accurate to at least one second, specification of the file requested, size of the file transferred, and the final status of the request. The log files for TUX are stored in /var/log/tux (as seen above) in binary format. In this binary format, the log files are approximately 50% smaller than standard ASCII text log files. To view log files issue the following command
# tux2w3c /var/log/tux 127.0.0.1 - - Wed Nov 20 00:22:24 2002 "GET /manual/sections.html HTTP/1.1" - 5523 200 127.0.0.1 - - Thu Nov 21 01:36:55 2002 "GET / HTTP/1.0" - 2890 200 127.0.0.1 - - Thu Nov 21 01:37:20 2002 "GET /manual/index.html HTTP/1.0" - 5557 200 127.0.0.1 - - Thu Nov 21 01:37:24 2002 "GET /manual/mod/index-bytype.html HTTP/1.0" - 6186 200The tux2w3c program converts the binary log files into into standard W3C-conforming HTTPD log files.
As we already know TUX is all about speeding up the response time. Using Gzip compression, it is also possible to reduce the download time as well as save some bandwidth. But for this feature to work the client must support Gzip compression. By default, this data compression is disabled. To enable it, do the following:
# echo 1 > /proc/sys/net/tux/compressionTo enable it at startup add the following line to /etc/sysctl.conf
net.tux.compression=1Also Gzip file with the extension .gz must be in the same directory as the uncompressed versions of the pages you wish to serve.
We are not finished with configuration yet. There are some more interesting features/tweaks which you can use. (Some of these are available only in RHCA v2.2)
As mentioned before, the recommended configuration is to use TUX as a front-end Web server listening on port 80(the default http port) and to use a back-end Web server (Apache is used here as an example) on port 8080 for answering requests that TUX does not understand (generally dynamically generated content eg.PHP pages). For this configuration, some changes have to be made to the httpd.conf file of Apache webserver.
Replace the line Port 80 with Port 8080 (port on which Apache will listen)Also to prevent users from bypassing TUX and directly accessing apache make the following changes. This may be necessary for security reasons.
Replace the line BindAddress * with BindAddress 127.0.0.1 (loopback address)Finally, restart httpd using
# service httpd restart
You can stop/restart TUX using the following commands:
# service tux stop (for RH-Systems) OR # ./tux-init stop (for non-RH Systems) # service tux restart OR # ./tux-init restartFor debugging purposes you can use the gettuxconfig script in the /usr/share/doc/tux-version/ directory. If you have an SMP system you can check whether all the interfaces have been setup properly using the checkbindings scripts. It is also present in the same directory.
As we have seen above, TUX helps a lot to improve the efficiency of webservers by shifting some of the operations from user-space to kernel-space. This results in better performance and better use of server resources. TUX is very configurable and has a number of interesting features. Hope you enjoyed the article. Happy Hacking!!