|
Advanced Virtual Server
Administration (2)
pg. 23
Most Internet servers require you to reboot the
physical machine or recompile the software whenever you make a change to its
configuration files. This is not the case with your Virtual Server. Your Virtual
Server knows when you make any changes to these files and immediately takes the
necessary steps to implement the changes.
There are a number of configuration files on your
Virtual Server that can be customized to change the way your Virtual Server
functions. It is the presence of these files, as well as your ability to change
them, that gives you an exceptional amount of freedom and flexibility.
Because these configuration files are so
important to your Virtual Server’s Web service, you should always exercise
extreme caution when modifying your configuration files. Be sure to make a
backup copy of the configuration file before editing it, in case something you
change causes your Virtual Server to stop functioning properly.
The commands issued within a configuration file
are called directives. Please note that directives are case sensitive;
therefore, you should pay close attention to capitalization and spacing to avoid
misconfiguring your Virtual Server.
This chapter discusses the four main
configuration files for your Virtual Server’s Web service. These files can be
found in your ~/www/conf or /usr/local/etc/httpd/conf directory. The main
configuration files are:
httpd.conf: The main configuration
file for your Virtual Server’s Web service, httpd.conf contains directives
relating to the operation of the Web service as a whole.
vhosts.conf: Contains directives
relating to your primary domain and virtual hosts.
access.conf: No longer used
mime.types: Assigns file types based
on filename extensions.
This chapter discusses some of the most common
settings that are modified in each of the above files, and describes the basic
purpose of each. Please be advised, however, that unless you understand what you
are doing you should not make changes to these files; otherwise, your server may
stop working properly.
The ~/www/conf/httpd.conf
File
The httpd.conf file is the main configuration
file for your Web service. It contains directives relating to the operation of
the server as a whole, and is therefore the file you are most likely to make
changes to.
Some of the more useful or important directives
in your httpd.conf file are:
HostnameLookups: This directive turns
on or off reverse DNS lookups in your log files. When off, the
Web server responds more quickly. When on, the server performs DNS
lookups every time a user hits the page. Although it can provide useful
information, the HostnameLookups option causes the Web server to respond more
slowly. For this reason, HostnameLookups is turned off by default.
ServerAdmin: This directive denotes the
email address that a visitor should contact in case of server problems. The
address is displayed through the browser in some error messages and is also
available in CGI scripts as a variable called SERVER_ADMIN. By default, the
ServerAdmin is set as the webmaster at yourdomain.com, but can be any
valid email address.
The following HTTP Log file directives specify
where to store your Web server logs. For each of the following directives, if
the location does not begin with a "/", the path is assumed to start in the
Server Root.
ErrorLog: Specifies the location to
log your Web server errors. It is useful for debugging CGI programs and
finding broken links on your Web site.
TransferLog: Specifies the location to
log the “hits” to your Web server.
AgentLog: Specifies the location to
log information about the types of Web browsers that are being used to visit
your site.
RefererLog: Specifies the location to
log the Web pages that "referred" a user to your site.
ServerName: Specifies the name of your
server. The server name MUST be a valid domain name that was assigned to you.
Please contact our Technical Support team if you have any questions about
changing your server name.
The
~/www/conf/vhosts.conf File
<VirtualHost></VirtualHost>: This
directive allows you to host additional domains on your Virtual Server. Any SRM
or ACCESS options can be placed between <VirtualHost> directives.
The vhosts.conf file also contains global
User/Password access control configurations for your server. By default, all
features are available to all visitors.
Because this information is important and
somewhat complex, we suggest you consult the online documentation at
http://www.apache.org/ before making
changes to this file.
Sectioning directives are placed between
<Directory></Directory> delimiters, and enforce extra restrictions on the
specified directory. AllowOverride is the most powerful directive because it
enables the default settings to be overridden within a specified directory. In
the following example, access control files are unrestricted in the
/usr/local/httpd/htdocs directory:
<Directory /usr/local/httpd/htdocs>
AllowOverride All
</Directory>
The AllowOverride directive may use any of the
following directives:
All. Removes restriction on access
control files within the specified directory.
None. No access control files are
allowed within the specified directory.
AuthConfig. Enables the use of
AuthType, AuthUserFile, and AuthGroupFile directives.
FileInfo. Enables the use of the
AddType and AddEncoding directives.
Limit. Enables the use of the Limit
sectioning directive.
Options. Enables the use of the
Options directive.
The directives enabled by the AuthConfig
directive include the following:
AuthName. Sets the authorization name
of this directory.
AuthType. Sets the authorization type
of this directory.
AuthUserFile. Specifies the file to
refer to for the list of users and passwords used in user authentication.
AuthGroupFile. Specifies the file that
lists user groups for user authentication.
The directives enabled by the Options directive
include the following:
All. All features are enabled for this
directory.
None. No features are enabled for this
directory.
ExecCGI. CGI scripts can be executed
in this directory.
Includes. Enables server-side include
files in this directory.
IncludesNoExec. Enables server-side
include files, but disables the exec server-side include command.
FollowSymLinks. Allows the server to
follow symbolic links.
SymLinksIfOwnerMatch. Allows the
server to follow a symbolic link only if the target file or directory is
owned by the same user ID as the link.
The Limit sectioning directive may use any of the
following directives:
allow hostname. Allows
specified hosts access to the server.
deny hostname. Denies specified
hosts access to the server.
order first, second. Specifies
the order in which the allow and deny directives are
processed. This can be either “allow, deny” or “deny, allow.”
require entity1 entity2 …
Entity values are authenticated users or groups that can access the system.
An entity can also be an explicit list of authenticated users such as those
listed with the AuthName directive.
Maximizing Web Server Performance
There are a number of things that can be done in your Web server configuration
files to greatly increase the speed and performance of your Web server. This
section contains suggestions for those who want to increase performance, and
assumes that you have a confident understanding of your main Web server
configuration files.
Reducing File System Lookups
Access Control Files: Placing .htaccess files in a directory allows you to
modify, add to, or override the settings contained in your Web server
configuration files for the contents of that directory, including any and all
subdirectories that it contains. This is commonly done as an easy way to make a
certain directory be an exemption to the rules that apply to the rest of the Web
server and is an alternative to editing the configuration files themselves. The
cost of this flexibility is a high one. When .htaccess file capability is turned
on, the Web server needs to check every directory in the path of the requested
file for the presence of .htaccess files before it can actually process the
request. This results in server slow down, especially if you have long paths in
the URL.
The solution for this is to disable .htaccess functionality, which is enabled by
default on your virtual server. This is done editing the AllowOverride directive
in the ~/www/conf/access.conf file for the www/htdocs directory so that it
reads:
AllowOverride None
Doing so will disable the ability to override configuration files and result in
faster performance. If you need to change settings for a specific directory,
make a separate <Directory> declaration in your ~/www/conf/access.conf file
instead of using .htaccess files. Be aware that if you currently use .htaccess
files to enable Server Side Includes, CGI execution, or other features, that
these also need to be defined in <Directory> declarations in
~/www/conf/access.conf or these features may stop working.
SymLink Verification: There is an option that can be used in various places in
your configuration files to allow or disallow following symbolic links in your
document tree. In most cases there are no problems with treating symbolic links
as directories. Placing this restriction on your Web server can slow your
performance considerably, as each directory in the path needs to be checked to
see if it is a link or not. To improve performance, consider use the
FollowSymLinks option in place and shy away from using the SymLinksIfOwnerMatch
option.
DNS
Lookup
By default, Apache 1.3.2 does not perform DNS lookups on the IP addresses of
your visitors before logging their activity in your Web server logs. Some people
however, enable the HostNameLookups directive in their ~/www/conf/httpd.conf
file because they like to see fully resolved domains in their logs instead of IP
addresses. Be aware that doing this slows your Web server down considerably. If
you need the domain information, consider doing it all at once when you analyze
your log files and not every time that a hit comes to your Web server. To
disable DNS lookup and get maximum performance, be sure that the following line
is found in your ~/www/conf/httpd.conf file:
HostNameLoookups Off
Parsed File Types
By default, .htm and .html files are defined in your ~/www/conf/mime.types file
as non parsed text files. This means that when a request for a .htm or .html
file comes in, your Web server simply finds the requested file and throws it
back to the visitor without looking at its contents. Also by default, .shtml,
and .php3 file types are defined in ~/www/conf/srm.conf as server parsed text
files for Server Side Includes and the PHP3 Apache module, respectively. This
means that any request for a .shtml or .php3 (or other file types that you
declare to be parsed files) causes the Web server to scan through the file line
by line looking for embedded commands to execute before returning the resulting
text back to the browser. The reason that these different file types are defined
in this way is so that only those pages that need to be parsed are parsed, and
pages that don’t need to be parsed are not. Occasionally, you may want to define
.html or .htm files to be parsed files as well, if you have for example, PHP or
SSI code in every page on your site. However, if only some of your pages need to
be parsed, stick with the default extensions for those files and leave the non
parsed extensions for the files that do not need to be parsed.
Configuration File Length:
Because your virtual server is on a shared system—where your Web server is
housed on the same physical machine as several others—your Web server is not
constantly running. Rather, it is started when needed, stays active for a while
as visitors browse your site, and then closes down after sitting idle for a
while. This prevents many idle Web servers from running at the same time and
causing unnecessary resource drains on the physical machine. This also allows
those Web sites that receive frequent traffic to use the resources that are
freed up by those sites that receive little or no traffic.
When a request comes in and your Web service
starts up after being idle for a while, it needs to read in the contents of your
configuration files before handling the request. To optimize performance at
these times, it may be a good idea to remove excess baggage from these files by
removing unnecessary comments or blocks of directives that may have
inadvertently been placed in there more than once. Doing so will reduce the
amount of time needed to parse through your configuration files when your Web
server starts up after being idle.
Invalid Virtual Host Names
When your Web server starts up, it attempts to verify the DNS information for
each of the domain names specified in your configuration files. Placing
<VirtualHost> entries in your configuration files that do not resolve properly
in DNS will cause your Web service to slow down considerably. For this reason,
you should not add virtual hosts to your configuration files until they
correctly resolve the DNS information. Also, be sure to remove or comment out
from your configuration files any virtual hosts that you are no longer using or
your Web service performance will decrease when the DNS information in no longer
accessible.
Limit the Number of Virtual Hosts
While we do not place an artificial limit on the number of Virtual Hosts that
you can host on a single virtual server, it is in your best interest not to
overload it. There are three main reasons for this:
First, having a large number of Virtual Hosts on
a single virtual server adds considerable length to your configuration files as
mentioned above. The typical Virtual Host declaration in your
~/www/conf/vhosts.conf file for a domain "domain.com" looks something like the
following:
<VirtualHost www.test.com>
ServerName www.test.com
ServerAlias test.com
ServerAdmin webmaster@test.com
DocumentRoot /usr/local/apache/vhosts/test.com/htdocs
ScriptAlias /cgi-bin/ /usr/local/apache/vhosts/test.com/cgi-bin/
TransferLog vhosts/test.com/logs/access_log
ErrorLog vhosts/test.com/logs/error_log
LogFormat "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\""
ErrorDocument 500 /errordocs/internalerror.html
ErrorDocument 404 /errordocs/filenotfound.html
ErrorDocument 403 /errordocs/accessdenied.html
</VirtualHost>
Second, having many popular sites hosted on a
single virtual server means that the server has to do more work. You may want
to consider ordering another Vserver or upgrading.
Finally, if you have separate log files for each
virtual host, be aware that the number of files that you can hold open at any
given time is limited. For each virtual host with separate log files, you're
likely adding at least four files to the list of open files that are being used.
Those can add up quickly if you host a large number of domains. The number of
open files, available RAM, simultaneous processes, and other resource
allocations depends on which type of virtual server product you have. At any
time, you can type "limit" from a SSH session and see what the resource limits
of your virtual server are.
Consider all of these factors in deciding when a
Virtual Server is "full" and when it is time to order additional ones or upgrade
to a larger virtual server product. Doing so will ensure better performance for
you and your customers.
Because different Web sites and Webmasters have
different needs, there is no single, magic answer for getting the best
performance from your virtual server's Web service. We hope that you find these
suggestions helpful to you.
Virtual Server Lite |
Virtual Server Standard |
Virtual Server Pro |
Virtual Server Ultra |
400 megs |
1000 megs |
1500 megs |
6000 megs |
Details |
Details |
Details |
Details |
Order |
Order |
Order |
Order |
| 
