 |
|
|
|
|
Setting up and Managing Virtual Servers
with Hit List
What are "Virtual Servers"?
A typical "Virtual Server" setup can best be explained
in the following context:
Let's say you start an Internet Service Provider company,
"Joe's ISP". And you have made a great effort to recruit
all sorts of business from your community for hosting
people's websites. Most of your marketing and advertising
points people to your website, Joe'sISP.com, where interested
companies can sign up and make arrangements. So at this
point you have one website, Joe'sISP.com on one "physical"
computer.
Based on your excellent advertising and marketing, Kevin,
Steve and Jeff come to you from three different companies
and pay you to host their respective sites. So you begin
to set up Kevin.com, Steve.com and Jeff.com, respectively.
At this point you usually have a choice - is my computer
up to the task of hosting all these sites (remember that
your own site, Joe'sISP.com, is already set up and working
on this computer)? If it is, then you would simply create
directories, assign IPs and such for these new three websites,
but you are still using only ONE physical computer. Here's
where the "virtual" comes in, as you may suspect. You
now have FOUR websites running on ONE computer, thus you
have FOUR "virtual" servers on ONE "physical" server (the
actual machine).
Each of these sites (yours, Kevin's, Steve's and Jeff's)
will typically produce a logfile of its activity, which
you know can be processed into the Hit List database for
accurate, flexible reporting on the data.
NOTE - the above example does NOT purport to explain
EVERY possibility for virtual servers out there (there
are probably hundreds of possibilities), only a
very typical situation.
What are the most common types of Virtual Servers?
The three typical ways most webmasters set up virtual
servers are: Host Header, IP or User Directory.
In the case of Host Header-based virtual servers, as
of this writing most webservers will not log this information.
Currently, the only webservers we've seen so far with
such modifications was an extremely customized Apache
logfile format, as well as Netscape (consult the Netscape
portion of the extended logging tech document). Without
such modifications (assuming they are possible, depends
on your webserver), only Hit List Live at this time
can thus track these types of virtual servers. If the
logs are modified in unique ways, you will likely need
to contact support@issel.co.uk
to discuss your webserver's configuration and logfiles,
to make sure Hit List can read them.
In the case of IP-based virtual servers, most webservers
will either separate out the logfiles according to virtual
server (IIS4.0, Apache, Netscape) or create one log
that tracks ALL virtual servers but puts in the virtual
serverÍs IP (IIS3.0, OÍReilly Website) so the hits can
be calculated according to the correct virtual server.
In the case of User Directory-based virtual servers,
what usually happens is that the website is organized
to put the content for specific virtual servers (for
example, a YourSite.com virtual server hosted by an
ISP) into specific directories on the webserver, so
the URLs all reflect it (ie /YourSite/default.htm for
the home page, /YourSite/adbanner.gif, and so on).
How can I manage/track my Virtual Servers with Hit
List?
Hit List has many powerful features that make working
with multiple virtual servers easy, but there are a few
initial steps involved.
Step 1. Configuring Your Server Logs.
This varies depending on your webserver, but is a
critical first step. Check our Extended Logging document to find
your server and how to set it up correctly.
Step 2. Configuring Hit List.
IP-Based Virtual Servers:
If your logs already have virtual site information
logged by default (IIS and O'Reilly WebSite), Hit
List will load virtual server information automatically.
Then you can use the built-in reports in the Virtual
Servers reports folder to report on one, several
or all of your vrtual servers either in individual
reports (Report for Each Virtual Server, Complete
Analysis for Each VS) or all in one overall report
(Virtual Servers Overall Report). Remember, as with
every report and element in Hit List, you can customize
these built-in reports or build your own in a similar
fashion. By default, Hit List will read your log
files and differentiate between virtual servers,
but still store all the data in one database file.
If your logs do NOT have server IPs recorded by
default (Apache, Netscape, Domino and other NCSA
servers) you will need to verify:
1) That the webserver is producing separate
logfiles in separate locations for each virtual
server. Apache and Netscape can do this without
a problem (although you may not have set this up
yet), consult your Apache or Netscape documentation.
Unfortunately, Lotus Domino cannot separate out
its logs according to virtual servers in its current
4.6 revision, but this has been purportedly fixed
in the forthcoming v5 (see our Using Lotus Domino document for more details).
2) That you have set up the appropriate
logfile paths under Options/Logfile to pull logs
from these locations - see our Setting Up Options document for more details.
3) That you are using our Enhanced NCSA Plugin to associate the virtual
server IPs with the appropriate logfiles to accomodate
the webserver not logging this IP.
User Directory-Based Virtual Servers:
The Hit List Virtual Server Manager is primarily
tasked with tracking and managing User Directory-based
virtual servers.
Important Note - The Virtual Server
Manager needs to be set up BEFORE building your
Hit List database! This is the most common error
encountered with using the Virtual Server Manager.
Setting up the Virtual Server Manager is fairly
simple. You begin by clicking New under "Virtual
Server Name" and filling in the name of the virtual
server, leaving the IP field blank (unless this
virtual server also has its own IP, it may or
may not) then hit Enter.
Now click New under "URL Root" and enter the
correct URL root down below, then hit Enter.
For example, YourSite.com might have a "Virtual
Server Name" of YourSite, leave the IP field
blank, then have a URL Root of /YourSite/. Thus
all content in the /YourSite/ that corresponds
to the virtual server YourSite will be accurately
tracked by Hit List as part of this virtual
server, and not simply a collection of URLs
on the overall website.
After you've put in the relevant Virtual Server
information, hit OK and exit the Virtual Server
Manager. Now update your database, and then run
a Virtual Server report to provide the information.
Step 3. Managing the Virtual Server data.
NOTE: Hit List Database Management/Speed topics are
covered in more detail in the Database
Management and Speed Tips tech document. Refer to
this document in addition to the suggestions below.
1) Size and Database Growth considerations.
A Hit List Professional or Commerce database is limited
to 1GB in size (Access97 format and size restriction).
Moreover, updates and reports slow down as the database
grows. For this reason, it's advisable that you Optimize
and then eventually Cycle your database file(s) from
time to time. You can automate this process with the
Event Scheduler. See Help under Database Manager/Tools
for more information about these procedures.
For Hit List Enterprise and Live, when you use an
Oracle or SQL Server database instead of the Access
back-end, the "cycling" utility doesn't apply, but
Optimizing the databases on a regular basis is still
important, especially as the databases become enormous
(above 1GB) yet you have to continually add new data.
2) One Database vs. A Different Database for each
Virtual Server.
Although storing all the requests from multiple servers
in one database lets you easily run reports for each
virtual server, it may be more efficient to use several
databases instead. This primarily applies to sites
that receive a total, from all servers, of more than
about 10MB per day. If this applies to you, consider
the following:
a. Storing all the data in one database
- This makes it easy to use the automatic virtual
domain support and lets you choose between running
reports that focus on one (or more) virtual domains
or treat the entire set of domains as one. If you
choose this strategy, however, you should probably
carefully watch your database size and optimize and/or
cycle your database fairly often such as once a week
or once a month. Additionally, in most cases, you
can probably skip storing detail data allowing you
to store vastly more information before the database
grows very large.
b. Storing the data in multiple databases
- If all your sites get an approximately equal number
of requests, you can create a different database
for each site. If you use a web server
that produces one large file log with data from
multiple virtual servers (Microsoft IIS and O'Reilly
WebSite, for example), you can tell Hit List to
create a database with requests from just one of
those servers by entering the IP address of the
server (Microsoft IIS) or the name of the server
(O'Reilly WebSite) into the Server name or IP section
of the Database tab.
This method will produce much smaller individual
databases and precludes the need for any filtering
when running a report, which in turn means that
reports will run much faster than when using the
first method. But it also makes it impossible
to run just one report that shows "overall" combined
statistics.
c. Use both methods - A hybrid of the two
approaches might work best for you if you manage
several virtual servers but a small number of them
produce most of the traffic. For example, assume
you manage 20 virtual servers but one of them accounts
for 70% of the traffic. You can use one database
to store data from the 19 low-volume servers and
a different database to store the data from each
the high-volume server. Do this as follows:
Create a report with the information you want
to show for each server. Make a Copy of it.
For the first report, use the database overrides
as described above but enter the names or IPs
of all of the 19 smaller servers. Use a comma
to separate each name or IP. For example, 123.456.789.000,
123.456.789.001, etc. This database will contain
information from all of these servers so you can
use the Run this report for every virtual server
switch to run this report for 19 of your 20 servers.
For the second report, do the same as for the
first, but only enter the IP address or name of
the high-volume server. The "Run this report for
every virtual server" switch doesn't apply because
this database will only contain data about one
server.
|
|
|
|
|
