 |
» |
|
|
|
|
|
$Revision: 1.51 $
$Date: 2006/04/17 21:27:49 $
|
1 Abstract
HP-UX Workload Manager (WLM) can help you manage and prioritize these Apache-based workloads. This paper demonstrates various management techniques. In particular, it:
- Demonstrates the use of WLM with Apache processes, Tomcat, CGI scripts, and related tools using the HP-UX Apache-based Web Server
- Provides the framework so the reader can extend these concepts to commercial, Apache-based systems such as Oracle Internet Application Server and Websphere
- Illustrates general WLM workload separation and management techniques outside the classic enterprise data center
|
2 Goal: manage Apache controlled workloads
The Apache web server is a very popular front end for a number of different web-based systems. The basic Apache process, httpd, and other processes it starts and manages comprise much of the workload for many middle tier systems in the enterprise, including many resource-intensive workloads.
Beyond commercial packages, much of the emerging web services infrastructure is being built around Apache or Apache-managed workloads. These include such mechanisms as XML-RPC and SOAP interfaces implemented as CGI, mod_*, or servlets combined in various ways with Apache.
If the reader needs a more robust Apache-based web server for the enterprise, especially for a mission-critical environment, HP recommends the HP-UX Apache-based Web Server. Engineered through state-of-the art processes for the highest quality and tailored to run smoothly on the HP-UX platforms, the HP-UX Apache-based Web Server is a total solution for web serving deployment in the enterprise. The Open Source Apache Web Server software developed by the Apache Software Foundation (Apache HTTP Server Project described at http://httpd.apache.org) serves as the foundation for the HP-UX Apache-based Web Server. In addition to the base HTTP server, HP has combined numerous popular modules from other Open Source projects as well as HP-developed valued features, such as performance tuning, user guides, and security modules, so the HP-UX Apache-based Web Server is highly optimized for the HP-UX PA-RISC and the Itanium Processor Family (IPF) operating systems.
If the reader is already using Apache-based workloads, the WLM workload separation techniques described in this paper can be used as well, although some path name and configuration file changes may need to be made.
|
3 Target audience
The discussion of use cases and management techniques should be accessible to most technical professionals with some UNIX background. The detailed information on applying changes to various configuration files may require previous knowledge of Apache, CGI, and servlet containers.
|
4 Target workloads and resource separation
The workload separation described here is largely aimed at CPU-bound workloads, or sets of workloads that are contending for CPU resources. WLM can also control disk bandwidth and memory, but examples of those controls are described in other documentation, including the WLM User's Guide. Also, workloads that are contending for or limited by network resources are not covered here.
The workload-separation techniques described here are not substitutes for good security measures and isolation such as firewalls. If the workloads do not share the same level of trust or have differing needs for user or system security, do not use WLM to combine them. WLM workload groups provide resource consumption separation; however, because the workloads share an HP-UX operating system instance, WLM does not provide the type of isolation offered by hardware partitions or systems separated by a firewall.
|
5 Review of WLM workload separation mechanisms
To understand what tools we have at our disposal to separate and control workloads, this section provides a quick overview of WLM groups and separation. Much more information on operation of WLM can be found in the WLM User's Guide and the wlm(5) man page. These documents are available on systems with WLM installed or by following the links at http://www.hp.com/go/wlm.
For information on how Apache processes equate to workloads, see the Apache process layout section. The processes are placed into a workload group whose resources are subject to allocations.
|
| 5.1 WLM overview
WLM controls workloads on HP-UX servers based on WLM workload groups. You define the workload groups and assign applications and users to the groups. WLM then adjusts the CPU allocations for the groups based on your defined service-level objectives (SLOs). WLM can also control memory and disk bandwidth allocations for the workload groups. (In the WLM context, a 'workload' is a group of HP-UX processes that jointly perform some work.)
WLM has two types of workload groups:
- FSS workload groups
With these groups, WLM uses the Fair Share Scheduler (FSS) to allocate CPU based on CPU time slices. A given FSS group is provided with a particular share of the CPU allocation across all CPUs in the system. This provides good resource sharing, as the CPU allocation is very fine, but provides very little isolation and limited CPU locality.
- PSET workload groups
WLM can use PSETs (processor sets) as the foundation for workload groups. For these groups, WLM manages the number of CPUs assigned to the underlying PSETs. A PSET offers its processes dedicated CPUs--no other processes on the system can access those CPUs.
WLM can also manage CPUs across either:
- virtual partitions (vPars)
or
- nPartitions (nPars) that use Instant Capacity cores
vPars offer dedicated resources to their processes. In addition, a vPar has its own instance of the HP-UX operating system, providing OS isolation. nPars also offer dedicated resources and their own instances of HP-UX. In addition, nPars offer hardware isolation. With Instant Capacity, CPU resources are installed on a system but are not available for use until purchased. This feature allows you to buy a system that meets current needs but also provides a quick and efficient upgrade path.
With virtual partitions (vPars), WLM migrates CPUs between the vPars as their respective SLOs demand. Using nPars that have CPU resources managed by Instant Capacity software, WLM can deactivate CPU resources on one nPar and activate a purchased but inactive Instant Capacity core on another nPar that needs the CPU resource more. This pseudo-movement of CPUs ensures resources are available where they are needed without incurring the charge of purchasing more CPU resources.
To summarize, WLM can manage the items in the following table.
|
| Item managed |
CPU is allocated in |
OS isolation |
Hardware isolation |
| FSS workload groups |
Ticks |
No |
No |
| PSET workload groups |
Whole CPUs |
No |
No |
| vPars |
Whole CPUs |
Yes |
No |
| nPars |
Whole CPUs |
Yes |
Yes |
| While FSS workload groups provide very flexible CPU allocation, they provide no OS or hardware isolation. Conversely, vPars and nPars offer more isolation, but CPU allocation is less flexible and administration overhead is increased. |
| 5.2 WLM's separation mechanisms
WLM provides several methods to place processes in workloads groups. It is important to understand these methods as they form the basis of our Apache workload separation methods. First, let's see how we define these workloads. The following snippet from a WLM configuration file creates three workload groups: servers_grp, apache_grp, and OTHERS.
|
prm {
groups = OTHERS : 1,
servers_grp : 2,
apache_grp : 3;
}
| Note that each workload group is given a name and a number. Later sections of the WLM configuration file then assign resource allocations to the groups. Processes within the groups then share the allocation for that group. The following sections explore how processes are placed in defined workload groups.
|
| 5.2.1 Application records: Workload separation by binary name The first mechanism to separate workloads is an 'app record'. This simply names a particular application binary and the group in which it should be placed.
The following app record causes the application manager to place any newly running /opt/hpws/apache/bin/httpd executables into the group apache_grp.
|
prm {
groups = OTHERS : 1,
servers_grp : 2,
apache_grp : 3;
apps = apache_grp : /opt/hpws/apache/bin/httpd ;
}
| 5.2.1.1 Apache binary locations The example above and the example configuration files in this toolkit show the default path to httpd for the HP-UX Apache-based Web Server on PA-RISC, which is /opt/hpws/apache/bin/httpd. Your httpd may be in a different location. If you used the /opt/hpws/apache/util/altroot.sh utility to relocate Apache or have Apache for a different HP-UX platform, you will need to modify the example to match your httpd location.
For instance, here is an example app record setup that looks for httpd in three different locations and places any or all that are run in apache_grp:
|
prm {
groups = OTHERS : 1,
servers_grp : 2,
apache_grp : 3;
# specify paths to default locations for apache 1.3,
# apache 2.0, and IPF 32 bit apache 2.0 respectively
apps = apache_grp : "/opt/apache/bin/*",
apache_grp : "/opt/hpws/apache/bin/*",
apache_grp : "/opt/hpws/apache32/bin/*"
;
}
| This setup has the advantage of placing any binary run from any of the three Apache directories into apache_grp, but may produce warnings for items that do not exist (output modified for readability): |
Non-Fatal Warning(s)
====================
wlm: Application record executable "/opt/apache/bin/*" not found.
Modify pathname or create executable. (PRM-2036)
wlm: Application record executable "/opt/hpws/apache32/bin/*" not
found. Modify pathname or create executable. (PRM-2036)
| 5.2.2 NOTE on polling and timing of binary placement
It is important to realize that the process name in the app record is not placed in the workload group at fork() time. Rather, the application manager periodically polls for newly started processes that match app records. If it detects one or more, the processes are moved to their respective workload groups. For more information, see the application manager discussion in the WLM documentation.
|
| 5.2.3 User records: Workload separation by process owner UID Besides placing particular binaries into groups, processes can be placed according to their owner's UID. User records are used for this purpose. Here is an example:
|
prm {
groups = OTHERS : 1,
testers : 2,
coders : 3,
surfers : 4;
users = moe : coders surfers,
curly : coders surfers,
larry : testers surfers;
}
Besides the default OTHERS group, this example has three groups of users: testers, coders, and surfers. The user records cause processes started by users moe and curly to be run in group coders by default, and user larry's processes to be run in group testers by default. Each user is also given permission to run jobs in group surfers if they wish, using the prmrun or prmmove commands mentioned below. Users not belonging to either group are placed in OTHERS by default.
See the PRM and WLM documentation for information on group permissions and precedence of user and app records.
|
5.2.4 prmrun: starting a process in a workload group
Besides placing processes in groups with user records or app records, you can explicitly start processes in particular groups using the PRM command prmrun. Given the group and user records described above, user larry running the command: % my_really_big_job &
testers. However, running % prmrun -g surfers my_really_big_job &
surfers.
This has particular application to Apache, as it can be used to run httpd and its children directly in a group: % prmrun -g apache_grp /opt/hpws/apache/bin/apachectl start
% prmrun -g apache_grp /opt/hpws/tomcat/bin/startup.sh
5.2.5 prmmove: moving an existing process to a workload group
In addition to using prmrun to start new processes in particular groups, you can move existing processes to a new group with the PRM command prmmove. If larry from the above example has a job running with process ID (PID) 4065 running in group testers, he could move that process to group surfers by running the command: % prmmove surfers -p 4065
For Apache, which runs as a daemon and becomes the leader of its own process group, sweeping all members of httpd's process group into a workload group is quick and easy. Here we use the contents of the stored PID file to locate httpd's PID. Because httpd is a daemon, its PID is also its process group ID, so we sweep the process group into the workload group apache_grp: % prmmove apache_grp -g `cat /opt/hpws/apache/logs/httpd.pid`
5.3 Default: inheriting workload group from parent process
If a process is not named by an explicit user record or app record, or has not been started with prmrun or moved with prmmove, it simply starts and runs in the same group as its parent process. So for a setup like this: prm {
groups = OTHERS : 1,
mygrp : 2;
}
mygrp, any process spawned by that shell process would also run in group mygrp because its parent process was there. Simple inheritance is the mechanism that determines where most processes run, especially for short-lived processes.
6 WLM workload and resource monitoring tools
There are a wide variety of tools available to help you monitor the process placement as well as resource allocation and usage of your workloads.
- wlminfo(1M)
command-line tool to monitor wlmd or wlmpard SLO status, metrics, and workload group allocation and usage
- wlmgui(1M)
graphical tool to monitor a single or multiple machines' WLM setup
- prmmove(1M), prmrun(1M)
tools to place processes in workload groups
- ps(1) -R, ps(1) -P
tools to see processes' current workload group
Please see the WLM User's Guide or the commands' man pages for more information on the exact usage of these commands. |
7 Review of Apache process structure
The Apache web server is highly configurable and has a wealth of modifications, utilities, modules, and platforms available on the web. Most 2.x Apaches running on HP-UX platforms will have a set of running processes similar to the layout in the figure below.
|
| 7.0.1 Figure: default HP-UX Apache-based Web Server layout |
| 7.1.1 Apache httpd processes As you can see from the figure above, there are several groupings. The far left represents the httpd parent process. Its children httpd processes are the processes that actually service HTTP requests. If Apache is started by root, the parent Apache httpd process is running as UNIX user root. For security, the httpd children are not run as root, but run as the UNIX user and group specified by the User and Group directives in /opt/hpws/apache/conf/httpd.conf. For the example setup, we have chosen User 'www' and Group 'other'. Also, when using the default setup, the process ID (PID) of the parent Apache process is stored in /opt/hpws/apache/logs/httpd.pid.
|
| 7.1.2 Apache modules: mod_* Within the parent and children processes, some add-on or third party |
| 7.1.3 Common Gateway Interface (CGI) processes Also shown are CGI processes. In most Apache setups, these are short-lived processes that are executed by the httpd children to service a single HTTP request. They return results to the httpd process and then exit. If the httpd processes usemod_cgi to spawn CGI processes, those processes are forked by whichever httpd services the CGI HTTP request. If the httpd processes use mod_cgid, one special httpd process will fork all CGI processes. For the HP-UX Apache 2.x series, mod_cgid is the default. See the Apache documentation for more information on mod_cgi and mod_cgid.
Examples and methods for separating and controlling CGI-based workloads are described in the section CGI workloads and short-lived children.
|
| 7.1.5 non-Apache processes
Many Apache-based systems contain workloads that are not direct children of the Apache httpd processes, such as databases, batch work of various types, other daemons to service ftp or ssh, and so forth. These workloads are part of the overall application, but can be separated from the Apache processes fairly easily. See the section Apache and non-web workloads for more information on separation of non-Apache workloads.
For more information on using Workload Manager with an Oracle database or a long-running batch job, see the Oracle Database Toolkit and the Duration Manager Toolkit chapters in the Toolkit User's Guide, available from http://docs.hp.com.
|
8 Demonstration platform
The techniques outlined here can be applied to many versions and configurations of Apache. The packages used in the write-up are:
- HP-UX Workload Manager (WLM) Version A.02.02 B8843CA
The Workload Manger product controls the disk, memory, and CPU resources available to given tasks.
- HP-UX Apache-based Web Server B.1.0.09.01 based on Apache version 2.0.47
HP has integrated the core Apache Web Server with numerous popular Open Source modules and HP value-added features to create HP-UX Apache-based Web Server, which is HP-certified for optimized performance with high quality testing and fully supported for the enterprise requiring mission-critical capabilities.
Readers can download the latest no-charge version of HP-UX Apache-based Web Server. Download instructions are available at http://www.hp.com/products1/unix/webservers/apache/.
- HP's perl B.5.6.1.C or later available from http://www.hp.com/go/softwaredepot/
As described in the HP Apache config.notes, installing perl will enable the use of mod_perl, webmin, and several other useful utilities, including those described in this toolkit, and several of the example workloads used to demonstrate the resource separation.
These workloads and utilities expect perl B.5.6.1.C to be located at /opt/perl/bin/perl. If your system's perl is in a different location, you will need to create symbolic links from your perl to use these utilities and workloads.
- root access
Many of the configuration and Apache control tasks require superuser access on the host HP-UX machine
|
9 Common setup steps: getting started
|
| 9.1 Installing perl5 While not absolutely required by httpd, installing perl5 is useful for Apache mod_perl tasks, and for the WLM Apache toolkit tools. The version used in developing this paper is perl B.5.6.1.C which is available from http://www.hp.com/go/softwaredepot/
After installation, the perl executable will be available at /opt/perl/bin/perl. Use this command to confirm that your installation is correct:
|
% /opt/perl/bin/perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
(much output removed)
CONTEXT
Locally applied patches:
ActivePerl Build 627
Built under hpux
Compiled at Jun 20 2001 21:42:53
@INC:
/opt/perl/lib/5.6.1/PA-RISC1.1-thread-multi
/opt/perl/lib/5.6.1
/opt/perl/lib/site_perl/5.6.1/PA-RISC1.1-thread-multi
/opt/perl/lib/site_perl/5.6.1
/opt/perl/lib/site_perl
.
| 9.2 Installing HP's Apache
As discussed above, HP's Apache will be used to demonstrate the workload separation techniques. The revision used here is HP-UX_Apache-based_Web_Server/2.0.47 available from http://www.hp.com/go/softwaredepot/
Use this command to confirm that your installation is similar:
|
% /opt/hpws/apache/bin/httpd -v
Server version: HP-UX_Apache-based_Web_Server/2.0.47
Server built: Oct 8 2003 05:29:46
Follow the rest of the installation instructions, including setting up the httpd.conf file until you have httpd running and serving web pages.
|
10 Tools to aid Apache monitoring and management
|
| 10.1.1 ab
The ab tool, included with the Apache distribution at /opt/hpws/apache/bin/ab, is a tool to test and time HTTP fetches. We will use ab to do repeated fetches, which will stress the Apache installation and consume resources allowing us to confirm that the resources are being consumed in the correct workload group.
Ideally, you will run the ab tool tests from a different machine, performing the HTTP fetches over a LAN. However, you can use ab directly on the host running Apache, although the ab tool itself will consume some CPU resources and of course no network latencies will be included in the measurements.
|
| 10.2 HP-UX Web Server Suite tools The HP-UX Web Server Suite includes a number of tools that are useful in configuring and managing your Apache. See the HP-UX Web Server Suite documentation for more information.
|
| 10.3 WLM/Apache toolkit utilities |
| 10.3.1 wlm_watch.cgi To enable simple WLM and workload monitoring tasks via the web, a script wlm_watch.cgi is included in the WLM Apache Toolkit. To enable it, copy it to the Apache cgi-bin directory:
|
% cp /opt/wlm/toolkits/apache/bin/wlm_watch.cgi /opt/hpws/apache/cgi-bin/
| and then point a browser at http://mymachine/cgi-bin/wlm_watch.cgi. The menu options invoke some of the WLM and PRM tools to read and monitor workload groups and their usage. wlm_watch.cgi requires perl5 and and perl5's CGI.pm. |
| 10.4 WLM/Apache toolkit dummy workloads To aid in testing the workload separation, a small set of dummy workloads have been included with the toolkit. Source code listings for the workloads are also available in Appendix B.
|
| 10.4.1 pig.cgi
The pig.cgi workload is a simple CGI-based workload that loops, wasting CPU resources. It is used to test the resource separation in several of the scenarios outlined later in this paper. pig.cgi requires perl5 and and perl5's CGI.pm.
The examples below showing the installation and use of pig.cgi assume that ScriptAlias is set to its default location in the /opt/hpws/apache/conf/httpd.conf file:
|
ScriptAlias /cgi-bin/ "/opt/hpws/apache/cgi-bin/"
| The examples also assume the appropriate Allow and Deny directives are set. |
| 10.4.2 PigServlet.java
PigServlet.java is a simple Java servlet workload that loops, wasting CPU resources. It is used to test the servlet resource-separation scenarios outlined later in this paper. In order to be used, PigServlet.java will need to be compiled into PigServlet.class using Tomcat's servlet.jar. For example, these steps produced a working .class file:
|
% cp /opt/wlm/toolkits/apache/workloads/PigServlet.java \
/opt/hpws/tomcat/webapps/examples/WEB-INF/classes/
% cd /opt/hpws/tomcat/webapps/examples/WEB-INF/classes/
% /opt/java1.3/bin/javac \
-classpath /opt/hpws/tomcat/common/lib/servlet.jar \
/opt/hpws/tomcat/webapps/examples/WEB-INF/classes/PigServlet.java
| These steps vary with the users's Java and Apache setup. Once it's built, you can then access the servlet at: http://mymachine/examples/servlet/PigServlet
|
| 10.4.3 pig.php The pig.php file is a simple, but computationally-expensive PHP page. It is used to test the mod_* workload resource-separation scenarios outlined later in this paper.
|
| 10.4.4 workload_wrapper The workload_wrapper file is a simple wrapper script to demonstrate forcing CGI execution in a particular workload group.
|
| 11 Apache and non-web workloads |
| 11.1 Separating Apache from Oracle database instances: fixed allocations
11.1.0.1 Goal For the first example, we have a system that is running Apache and an Oracle database instance. To keep either from being starved by excessive activity, we've decided to create a workload group apache_grp in which to place Apache and its children, and a workload group oracle_grp in which to place the processes that make up the Oracle instance.
For this setup, we will use the apache_vs_oradb.wlm configuration file. (The contents of all example .wlm files are available in Appendix A of this document and in the directory /opt/wlm/toolkits/apache/config/.) The groups are given fixed allocations of 45 shares each. Nonroot jobs besides Oracle and Apache run in the remaining 10 shares left to OTHERS. Below is a diagram showing the separation the .wlm file will achieve.
11.1.0.2 Figure |
11.1.0.3 Making it happen
Let's give it a try. We make a copy of the example configuration then start WLM with that copy:
% cp /opt/wlm/toolkits/apache/config/apache_vs_oradb.wlm \
/home/myhome/apache_vs_oradb.wlm
% wlmd -a /home/myhome/apache_vs_oradb.wlm
and then view the groups we've set up:
% wlminfo groups
Fri Nov 7 13:34:43 2003
Workload Group PRMID CPU Shares CPU Util Mem Shares State
OTHERS 1 10.00 0.00 0.00 ON
oracle_grp 2 45.00 0.00 0.00 ON
apache_grp 3 45.00 5.74 0.00 ON
and then (after a few seconds), see that the httpd processes have been moved into the apache_grp workload group:
% ps -P -R apache_grp
PRMID PID TTY TIME COMMAND
apache_grp 27196 ? 0:00 httpd
apache_grp 27194 ? 0:00 httpd
apache_grp 27195 ? 0:00 httpd
apache_grp 27193 ? 0:00 httpd
11.1.0.4 Apache configuration modifications No modifications to the Apache configuration are necessary.
11.1.0.5 Using test workloads to confirm the separation
Now, to see how CPU resources are contained by the workload groups, we cause the workloads to consume (CPU) resources. Driving the Oracle database workload is highly dependent on the connection method and is not specific to Apache, so it will not be covered here. To stress the apache_grp workload, let's use a dummy CGI workload to consume resources. An example CGI workload, /opt/wlm/toolkits/workloads/pig.cgi, is just an easy, CPU-intensive way of seeing the workload separation. Copy the workload to the cgi-bin directory:
% cp /opt/wlm/toolkits/apache/workloads/pig.cgi \
/opt/hpws/apache/cgi-bin/pig.cgi
and then use a browser to confirm that fetching the URL http://mymachine/cgi-bin/pig.cgi works. To test resource consumption, simply do a series of URL fetches with the ab tool to stress httpd. To see the resources usage, start a wlminfo group -l command. (You can run the wlminfo command in a different window or in the background with output to a file.) The usage will vary by hardware platform, but the CPU usage should always be concentrated in apache_grp. The ab tool will show the URLs being fetched and the time required:
% /opt/hpws/apache/bin/ab -n 10 http://mymachine/cgi-bin/pig.cgi
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.1 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking mymachine (be patient).....done
Server Software: HP-UX_Apache-based_Web_Server/2.0.47
Server Hostname: mymachine
Server Port: 80
Document Path: /cgi-bin/pig.cgi
Document Length: 864 bytes
Concurrency Level: 1
Time taken for tests: 19.637063 seconds
Complete requests: 10
Failed requests: 0
Write errors: 0
Total transferred: 10430 bytes
HTML transferred: 8640 bytes
Requests per second: 0.51 [#/sec] (mean)
Time per request: 1963.706 [ms] (mean)
Time per request: 1963.706 [ms] (mean, across all concurrent requests)
Transfer rate: 0.51 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 1945 1962 16.7 1957 1994
Waiting: 1939 1956 17.1 1951 1989
Total: 1945 1962 16.7 1957 1994
Percentage of the requests served within a certain time (ms)
50% 1957
66% 1965
75% 1972
80% 1987
90% 1994
95% 1994
98% 1994
99% 1994
100% 1994 (longest request)
The wlminfo group command will show the resources being consumed in the CPU Util. Here is a single interval's output from wlminfo group:
% wlminfo group
Fri Nov 7 13:34:13 2003
Workload Group PRMID CPU Shares CPU Util Mem Shares State
OTHERS 1 10.00 0.00 0.00 ON
oracle_grp 2 45.00 0.00 0.00 ON
apache_grp 3 45.00 5.23 0.00 ON
% wlminfo group -l
Fri Nov 7 13:34:43 2003
Workload Group PRMID CPU Shares CPU Util Mem Shares State
OTHERS 1 10.00 0.00 0.00 ON
oracle_grp 2 45.00 0.00 0.00 ON
apache_grp 3 45.00 5.74 0.00 ON
Fri Nov 7 13:34:58 2003
Workload Group PRMID CPU Shares CPU Util Mem Shares State
OTHERS 1 10.00 0.00 0.00 ON
oracle_grp 2 45.00 0.00 0.00 ON
apache_grp 3 45.00 2.41 0.00 ON
Fri Nov 7 13:35:13 2003
Workload Group PRMID CPU Shares CPU Util Mem Shares State
OTHERS 1 10.00 0.00 0.00 ON
oracle_grp 2 45.00 0.00 0.00 ON
apache_grp 3 45.00 0.00 0.00 ON
11.1.0.6 Further discussion, links
You can also use Glance or gpm to see the PRM groups and resource consumption of those groups. (PRM groups are the basis for WLM's FSS workload groups.)
| 11.2 Separating Apache httpd from batch work: conditional allocations
11.2.0.1 Goal Our second example will be slightly more complex than the first. Imagine we have a system that is running Apache and also is occasionally used for batch work. However, the batch work is quite important, so when the batch jobs are run, they need to have half the resources set aside for them. When no batch work is running, the bulk of the machine resources should be made available to Apache.
11.2.0.2 WLM setup Again, we've created a workload group apache_grp in which to place Apache and its children, and, showing a complete lack of imagination, the batch jobs will be run in a group batch_grp. The apache_vs_batch.wlm file is in Appendix A.
The batch_grp is given an allocation of 50 shares, but this is active on the condition that there are active processes running in the group. To make interactive login performance acceptable, nonroot jobs besides batch and Apache running in OTHERS are given 10 shares. The remaining shares are given to the apache_grp, as it is constantly requesting 90 shares, albeit at a low priority.
Below is a diagram showing the separation the .wlm file will achieve when batch jobs are active.
11.2.0.3 Figure |
11.2.0.4 Apache configuration modifications
No modifications to the Apache configuration are necessary.
11.2.0.5 Making it happen
Let's give it a try. We make a copy of the example configuration then start WLM with that copy:
% cp /opt/wlm/toolkits/apache/config/apache_vs_batch.wlm \
/home/myhome/apache_vs_batch.wlm
% wlmd -a /home/myhome/apache_vs_batch.wlm
(NOTE: You will receive a warning if you do not actually have an executable on your system called /opt/batch/bin/my_big_batch_job.)
Now view the groups we've set up:
% wlminfo group
Fri Nov 7 13:44:03 2003
Workload Group PRMID CPU Shares CPU Util Mem Shares State
OTHERS 1 10.00 0.00 0.00 ON
batch_grp 2 1.00 0.00 0.00 ON
apache_grp 3 89.00 0.00 0.00 ON
(Note that batch_grp has only a 1% allocation because no batch jobs are running yet.) After a few seconds, see that the httpd processes have been moved into the apache_grp workload group. In this case, we used prmrun to run some simple CPU-eater scripts in batch_grp, and observed this for usage:
% wlminfo groups
Fri Nov 7 13:45:03 2003
Workload Group PRMID CPU Shares CPU Util Mem Shares State
OTHERS 1 10.00 0.00 0.00 ON
batch_grp 2 50.00 12.51 0.00 ON
apache_grp 3 40.00 0.00 0.00 ON
% wlminfo metrics
Fri Nov 7 13:45:03 2003
Metric Name PID State Value
active_batch_job_count 28142 NEW 2.000000
% wlminfo slo
Fri Nov 7 13:45:03 2003
SLO Name Group Pri Req Shares State Concern
OTHER_fixed_slo OTHERS 1 10 10 PASS
batch_conditional_sl batch_grp 2 50 50 PASS
apache_request_the_r apache_grp 3 90 40 FAIL Priority
% ps -PR batch_grp
PRMID PID TTY TIME COMMAND
batch_grp 28163 pts/1 2:44 my_big_batch_j
batch_grp 28162 pts/1 2:45 my_big_batch_j
11.2.0.6 Using test workloads to confirm the separation
The Apache workload can be stressed using the pig.cgi workload as shown in the previous example. Use wlminfo group to see the CPU allocation and usage. You'll notice that despite activity in apache_grp, the batch_grp allocation remains a token 1 share because the ACTIVE_PROC_CNT condition for the batch_active_proc_slo has not been met.
To see the batch allocation become active, run some process in batch_grp that will last several seconds and then use wlminfo group to confirm that the allocation for the batch_grp has become active:
% wlminfo group
Fri Nov 7 13:45:03 2003
Workload Group PRMID CPU Shares CPU Util Mem Shares State
OTHERS 1 10.00 0.00 0.00 ON
batch_grp 2 50.00 12.51 0.00 ON
apache_grp 3 40.00 0.00 0.00 ON
% wlminfo metric
Fri Nov 7 13:45:03 2003
Metric Name PID State Value
active_batch_job_count 28142 NEW 2.000000
% wlminfo slo
Fri Nov 7 13:45:03 2003
SLO Name Group Pri Req Shares State Concern
OTHER_fixed_slo OTHERS 1 10 10 PASS
batch_conditional_sl batch_grp 2 50 50 PASS
apache_request_the_r apache_grp 3 90 40 FAIL Priority
You can see that the allocation for batch_grp has become active because jobs were run in it. When real /opt/batch/bin/my_big_batch_job jobs are run, WLM places them in batch_grp. Because there are now active processes in the group, batch_conditional_slo kicks in and 50 shares are allocated to batch_grp.
11.2.0.7 Further discussion, links
You can use conditions besides ACTIVE_PROC_CNT to enable/disable SLOs, including dates, times, Glance metrics, external metrics via wlmsend, and Serviceguard package failover status using the sg_package_active utility.
Other examples illustrating conditional allocations can be found at /opt/wlm/examples/wlm_config/metric_condition.wlm and the 'boost' examples in /opt/wlm/toolkits/oracle/config/.
| 12 CGI workloads and short-lived children |
| 12.1 Isolating an individual resource-intensive CGI workload
12.1.0.1 Goal Example: The administrator of an Apache system notices after some analysis of resource consumption (using top) that users hitting a particular CGI-based URL http://mymachine/cgi-bin/really_big_pig.cgi are negatively affecting the overall performance of his system. He'd like to throttle the resource consumption of that particular CGI script, isolating it from the rest of the Apache processes and CGI scripts.
(Experiments with the Apache RLimitCPU directive show him that the Rlimit* directives affect *all* CGI scripts, and do not provide the absolute control or prioritization he seeks.)
To accomplish the separation, we place Apache and its children in the by-now-familiar apache_grp container. We then wrap the offending CGI script in a small POSIX shell script that simply does a prmrun into the 'penalty box' group, cgi_jail_grp.
The basic group allocation is controlled by the SLO cgi_jail_conditional_slo using the metric active_cgi_job_count. If no CGI processes are active in the cgi_jail_grp, only a token allocation is given to cgi_jail_grp. If at least one CGI process is active in the group, cgi_jail_conditional_slo is active and a base allocation is given to the group.
As more CGI processes are started in cgi_jail_grp, the SLO cgi_jail_conditional_slo_offset provides additional CPU allocation to the group. This allows httpd processes waiting on the CGI output to get their results back more quickly while still isolating httpd processes that are performing other work.
12.1.0.2 Figure |
| 12.1.0.3 Apache configuration modifications No modifications to the Apache configuration are necessary.
12.1.0.4 WLM setup The WLM configuration file apache_vs_single_cgi.wlm sets up two groups: cgi_jail_grp to hold the single CGI resource hog and apache_grp for Apache and all other child processes. We make a copy of the example configuration then start WLM with that copy:
|
% cp /opt/wlm/toolkits/apache/config/apache_vs_single_cgi.wlm \
/home/myhome/apache_vs_single_cgi.wlm
% wlmd -a /home/myhome/apache_vs_single_cgi.wlm
The processes are placed in apache_grp with the app records, while the CGI resource hog, really_big_pig.cgi, is forced into the cgi_jail_grp group with the workload_wrapper script. An example of installing and editing workload_wrapper is shown below.
12.1.0.5 Using test workloads to confirm the separation
For testing, we need a really_big_pig.cgi script, so let's use our usual pig, pig.cgi:
% cp /opt/wlm/toolkits/apache/workloads/pig.cgi \
/opt/hpws/apache/cgi-bin/really_big_pig.cgi
Test that the URL http://mymachine/cgi-bin/really_big_pig.cgi works. This should adequately represent that starting state of the scenario.
Now, to separate the individual CGI script, move it to the side to a contrived name:
% mv /opt/hpws/apache/cgi-bin/really_big_pig.cgi \
/opt/hpws/apache/cgi-bin/really_big_pig.cgi.real
% cp /opt/wlm/toolkits/apache/workloads/workload_wrapper \
/opt/hpws/apache/cgi-bin/really_big_pig.cgi
and then edit the contents of /opt/hpws/apache/cgi-bin/really_big_pig.cgi to have it invoke /opt/hpws/apache/cgi-bin/really_big_pig.cgi.real by changing lines
TARGET_PRM_GRP=name_of_your_PRM_grp
TARGET_PRM_BIN=name_of_your_real_cgi_script
to
TARGET_PRM_GRP=cgi_jail_grp
TARGET_PRM_BIN=/opt/hpws/apache/cgi-bin/really_big_pig.cgi.real
This setup will now use workload_wrapper to prmrun the real CGI script in our penalty box group. This requires an extra fork/exec step, but we've already determined that this is a long-running, resource-intensive job, so the impact of inserting the extra step should be minimal. To test the arrangement, use the normal method of repeatedly running some other CGI script to confirm that all resource consumption is in apache_grp:
% /opt/hpws/apache/bin/ab -n 40 -c 4 http://mymachine/cgi-bin/pig.cgi
and then wlminfo group will show the resources being used in apache_grp. Now repeatedly run the target CGI URL to see that it consumes resources in cgi_jail_grp:
% /opt/hpws/apache/bin/ab -n 40 -c 4 \
http://mymachine/cgi-bin/really_big_pig.cgi
and then a quick run of wlminfo group will show the resources being used in cgi_jail_grp.
12.1.0.6 Further discussion, links
A similar wrapper script method can be used for mod_ssi command invocations. Commands that are run by:
[an error occurred while processing this directive]
can have a wrapper installed that executes the original script like the example above, or, if modifying the HTML source is an acceptable alternative, the prmrun command can be placed in the SSI.
[an error occurred while processing this directive]
This will execute the prmrun command which in turn executes the /my/path/mycmd in the cgi_jail_grp workload group.
| 12.2 Separating a managed CGI workload from other Apache workloads
12.2.0.1 Goal Alternative CGI mechanisms that use a long-running parent or container process to manage CGI workloads, such as FastCGI, are available as third-party additions to Apache. Because these are often used to speed CGI scripts and limit their resources, using WLM to separate, contain, and manage them would be beneficial.
12.2.0.2 Figure |
| 12.2.0.3 WLM setup Because they are not shipped as part of HP-UX Apache-based Web Server, step-by-step instructions for FastCGI and similar use cases will not be described further here. However, the steps outlined for separating Tomcat workloads should be similar to those required for persistent CGI frameworks.
|
13 Separating servlet workloads from other Apache workloads
Containers for Java-based servlets are important workloads in many Apache environments, and are used to perform a wide variety of tasks. The next section will provide examples of how to separate and control these servlet containers.
|
| 13.1 Separating all Apache Tomcat workloads from other Apache workloads
13.1.0.1 Goal In some Apache environments, the servlets may comprise a different workload or set of workloads from the rest of the httpd/modules/CGI environment. In this situation, separating the servlet container into its own workload group would be beneficial for resource separation. 13.1.0.2 Figure |
| 13.1.0.3 WLM setup The file apache_vs_tomcat.wlm, contains two workload groups, tomcat_grp and apache_grp.
Let's make a copy of the example configuration then start WLM with that copy:
|
% cp /opt/wlm/toolkits/apache/config/apache_vs_tomcat.wlm \
/home/myhome/apache_vs_tomcat.wlm
% wlmd -a /home/myhome/apache_vs_tomcat.wlm
13.1.0.4 Tomcat configuration modifications
We could use a WLM app record for the Java binary to separate Tomcat. However, an app record for our JVM, /opt/java1.3/bin/java would cause all Java processes that use /opt/java1.3/bin/java that use the JVM to be placed in the tomcat_grp, not just Tomcat. We'd like to be more specific in our separation, so we'll modify the Tomcat control script setup to explicitly place just Tomcat in tomcat_grp.
Also, we could just use a prmrun command each time we start Tomcat to start the scripts and JVM in the correct group like this:
cd /opt/hpws/tomcat/;
/opt/prm/bin/prmrun -g tomcat_grp ./bin/startup.sh
which will run the startup.sh script in the correct group.
However, with that approach, the admin needs to remember to use prmrun each time you start Tomcat, so let's modify the Tomcat startup script to place itself in the right group. In the file /opt/hpws/tomcat/bin/startup.sh, add these lines near the top of the script below the #!/bin/sh and beginning comment block:
# move ourselves to the workload group 'tomcat_grp'
/opt/prm/bin/prmmove tomcat_grp -p $$
These new lines will cause startup.sh to place itself in the group tomcat_grp before exec'ing the Tomcat JVM.
The httpd processes are placed in apache_grp by the application records in apache_vs_tomcat.wlm file, so no modifications to /opt/hpws/apache/bin/apachectl are needed. Now, stop Tomcat, restart it using the startup.sh script, and check that the workloads are running in the correct groups:
% ps -PR apache_grp
PRMID PID TTY TIME COMMAND
apache_grp 25687 ? 0:00 httpd
apache_grp 25686 ? 0:00 httpd
apache_grp 25684 ? 0:00 httpd
apache_grp 25683 ? 0:00 httpd
% ps -PR tomcat_grp
PRMID PID TTY TIME COMMAND
tomcat_grp 25627 pts/1 0:02 java
| 13.1.0.5 Using test workloads to confirm the separation Now, to see that the separation has occurred, we need to access a servlet. Let's use the PigServlet. Follow the instructions in the PigServlet.java description section to copy and compile the PigServlet.java. When finished, you should have PigServlet.class in /opt/hpws/tomcat/webapps/examples/WEB-INF/classes/. Now fetch the URL http://mymachine/examples/servlet/PigServlet repeatedly with ab while watching wlminfo group to see resources being consumed in tomcat_grp.
13.1.0.6 Limitations Tomcat must be started after WLM for this setup to operate correctly, as the Tomcat control script prmmove command will fail if the workload groups do not exist. Tomcat will run, but will not be in the correct group when WLM is started later. To place Tomcat after WLM has been started or restarted, you can manually use prmmove to move the running Tomcat JVM process to tomcat_grp.
13.1.0.7 Further discussion, links
Other servlet containers and persistent processes that are started and managed as children of Apache can be managed in a similar fashion. For instance, FastCGI executes CGI scripts within a long-running process that is a child of httpd. The startup sequence for FastCGI could be modified to use prmrun in a similar manner to the Tomcat startup.sh described above.
|
| 13.2 Separating high/lo priority Tomcat workloads using two Tomcat JVMs
13.2.0.1 Goal An application has a low priority servlet-based workload that is negatively affecting the resources for the rest of the higher priority servlet workloads. The user wishes to separate the single servlet into its own workload group. The servlet container used is Tomcat.
Because WLM operates on processes, it will be necessary to run the target servlet in a separate Tomcat container, running in a separate Java Virtual Machine process.
13.2.0.2 Figure |
13.2.0.3 WLM setup
The workload group arrangement laid out in apache_single_servlet.wlm is pretty simple--all Apache processes go in apache_grp and the resource hog servlet goes in servlet_jail_grp. To use resources as efficiently as possible, the allocation for servlet_jail_grp is conditional on having active processes running in the group, just like in apache_single_servlet.wlm above. Let's make a copy of the example configuration then start WLM with that copy:
% cp /opt/wlm/toolkits/apache/config/apache_single_servlet.wlm \
/home/myhome/apache_single_servlet.wlm
% wlmd -a /home/myhome/apache_single_servlet.wlm
13.2.0.4 Tomcat modifications
The default /opt/hpws/tomcat/bin/startup.sh and /opt/hpws/tomcat/conf/* files start just one Tomcat instance. We will construct configuration files and a start/stop script to execute a second Tomcat JVM.
13.2.0.5 mod_jk configuration file changes
Now we will configure Apache to split the mod_jk traffic destined for 'jail' URLs to a second Tomcat.
As part of this setup, we'll be working with mod_jk.conf and workers.properties files. Note that for different versions of the HP-UX Apache-based Web Server, these files may be in either /opt/hpws/tomcat/jk/apache2/ or /opt/hpws/apache/conf. The following examples use the /opt/hpws/tomcat/jk/apache2/ path, but you should use whichever path matches your existing mod_jk location.
Add the following lines to the end of your mod_jk.conf file:
JkMount /jail ajp13tomcat2
JkMount /jail/* ajp13tomcat2
and then in your workers.properties file, change the line
worker.list=ajp13
to
worker.list=ajp13, ajp13tomcat2
and add these lines to the end of the file:
worker.ajp13tomcat2.type=ajp13
worker.ajp13tomcat2.port=8010
worker.ajp23tomcat2.host=localhost
This will make Apache send URLs with /jail in them to a second Tomcat, which will listen for ajp13 traffic on port 8010.
13.2.0.6 Tomcat configuration file changes
Now, we need to create a second Tomcat instance to act as the servlet jail. This requires duplicate locations for logs, servlets, a duplicate config file, etc. The /opt/hpws/tomcat/GETTING_STARTED file describes some of these steps, and suggests that a simple way to have multiple Tomcats is to differ the settings of CATALINA_BASE. This is the approach we will take. Type the following commands or create a script to create the jail files and directories:
#!/bin/sh -x
#
# Commands to create a second Tomcat instance for use
# as a servlet jail. These only need to be run once,
# so create as a script in any location and execute.
#
# top is the location of the original Tomcat installation
# (and original CATALINA_BASE)
top=/opt/hpws/tomcat/
# jail is the location of the second CATALINA_BASE
jail=$top/jail
mkdir -p $jail/conf/
cp $top/conf/* $jail/conf/
mkdir -p $jail/logs
mkdir -p $jail/webapps/jail/WEB-INF/classes
mkdir -p $jail/work
mkdir -p $jail/temp
mkdir -p $jail/bin
#make everything owned by user www
chown -R www $jail
When completed, you will have a minimal but functional Tomcat setup at /opt/hpws/tomcat/jail.
You then need to configure the /opt/hpws/tomcat/jail/conf/server.xml file. The settings in this file will depend upon what types of servlets or facilities you need the second Tomcat to support, and you may need to consult the Tomcat documentation to complete the full server.xml customization steps.
There are two important points to keep in mind when setting up the jail Tomcat's server.xml:
- The org.apache.ajp.tomcat4.Ajp13Connector port needs to match the worker.ajp13tomcat2.type=ajp13 setting in the workers.properties file. That section of your jail server.xml will look like the following snippet
This causes the jail Tomcat to listen for ajp13 connections on port 8010, matching your Apache mod_jk worker.ajp13tomcat2.port setting. - The other port settings for other connectors do not collide with ports on which the first Tomcat is already listening. You will see error messages in the Tomcat logs if two Tomcats attempt to listen at the same port on the same host.
13.2.0.7 Tomcat jail start/stop scripts Next, create a jail start script like the following, placing it in the /opt/hpws/tomcat/jail/bin/ directory:
#!/bin/sh
# start a second copy of Tomcat as a resource-limited single servlet jail
#
# place this at /opt/hpws/tomcat/jail/bin/jail_startup.sh
/opt/prm/bin/prmmove servlet_jail_grp -p $$
export CATALINA_BASE="/opt/hpws/tomcat/jail"
export CATALINA_TMPDIR="/opt/hpws/tomcat/jail/temp"
export CATALINA_HOME="/opt/hpws/tomcat"
export JAVA_HOME="/opt/java"
# cd to CATALINA_HOME so catalina.sh script works right
cd $CATALINA_HOME;
$CATALINA_HOME/bin/startup.sh
Note that this script will prmmove itself and its child Tomcat JVM in the servlet_jail_grp, so it will need to be run after WLM is started. You may also wish to have a script to shutdown the jail like this:
#!/bin/sh
# shutdown the single servlet jail Tomcat instance
# - place this at /opt/hpws/tomcat/jail/bin/jail_shutdown.sh
#
export CATALINA_BASE="/opt/hpws/tomcat/jail"
export CATALINA_TMPDIR="/opt/hpws/tomcat/jail/temp"
export CATALINA_HOME="/opt/hpws/tomcat"
export JAVA_HOME="/opt/java"
# cd to CATALINA_HOME so catalina.sh script works right
cd $CATALINA_HOME;
$CATALINA_HOME/bin/shutdown.sh
Make sure the scripts are executable by the user you want to own and run Tomcat.
13.2.0.8 Tomcat default start/stop script We want the primary Tomcat instance to run with Apache in apache_grp. However, we have a user record for user www in the .wlm file that makes the default for www owned processes to be apache_grp. Because of this, we do not need a prmmove command in the default Tomcat startup.sh script.
13.2.0.9 Starting everythingOnce you've confirmed the settings, start the Tomcat jail with:
% /opt/hpws/tomcat/jail/bin/jail_startup.sh
Then start the normal Tomcat with:
% /opt/hpws/tomcat/bin/startup.sh
and start Apache with:
% /opt/hpws/apache/bin/apachectl start
Wait a few seconds, then confirm that the jobs are running in the correct groups:
% ps -eP | egrep 'httpd|java'
apache_grp 25449 ? 0:00 httpd
servlet_jail_grp 4379 ttyp2 0:48 java
apache_grp 25450 ? 0:00 httpd
apache_grp 25451 ? 0:00 httpd
apache_grp 4074 pts/0 1:15 java
apache_grp 25448 ? 0:03 httpd
Check the Tomcat and Apache error logs to make sure none of the workloads are experiencing any configuration problems.
13.2.0.10 Using test workloads to confirm the separation To see the resource separation, try a conventional servlet. Follow the instructions in the PigServlet.java description section to copy and compile the PigServlet.java. Fetch the URL http://mymachine/examples/servlet/PigServlet with ab several times and use wlminfo group to see resources being consumed in apache_grp.
% /opt/hpws/apache/bin/ab -n 50 \
http://mymachine/examples/servlet/PigServlet &
% wlminfo group -l
Tue Nov 11 23:52:40 2003
Workload Group PRMID CPU Shares CPU Util Mem Shares State
OTHERS 1 10.00 0.00 0.00 ON
servlet_jail_grp 2 20.00 0.00 0.00 ON
apache_grp 3 70.00 0.00 0.00 ON
Tue Nov 11 23:52:55 2003
Workload Group PRMID CPU Shares CPU Util Mem Shares State
OTHERS 1 10.00 0.00 0.00 ON
servlet_jail_grp 2 20.00 0.00 0.00 ON
apache_grp 3 70.00 4.80 0.00 ON
Now, use a workload that has a URL prefix that causes it to originate from the servlet_jail workload group. However, because we have a limited number of example servlet workloads (one - PigServlet), we'll make a second copy of the servlet you just built inside the servlet_jail.
cp /opt/hpws/tomcat/webapps/examples/WEB-INF/classes/PigServlet.class \
/opt/hpws/tomcat/jail/webapps/jail/WEB-INF/classes/PigServlet.class
Fetch the URL http://mymachine/jail/servlet/PigServlet several times and use wlminfo group to see resources being consumed in servlet_jail_grp. You've effectively used a different URL and servlet container to force the servlet resource consumption into a different workload group.
% /opt/hpws/apache/bin/ab -n 500 \
http://mymachine/jail/servlet/PigServlet &
% wlminfo group -l
Tue Nov 11 23:54:10 2003
Workload Group PRMID CPU Shares CPU Util Mem Shares State
OTHERS 1 10.00 0.00 0.00 ON
servlet_jail_grp 2 20.00 0.20 0.00 ON
apache_grp 3 70.00 0.01 0.00 ON
Tue Nov 11 23:54:25 2003
Workload Group PRMID CPU Shares CPU Util Mem Shares State
OTHERS 1 10.00 0.00 0.00 ON
servlet_jail_grp 2 20.00 4.92 0.00 ON
apache_grp 3 70.00 0.03 0.00 ON
13.2.0.11 Further discussion, links This same technique can be used for high-priority servlets instead of low-priority resource hogs. modules: mod_* workloads, httpd internal workloads, multiple Apaches
13.3 Separating two departments' applications using two Apaches
| 13.3.0.1 Goal A particular application hosts a custom servlet-based finance application and an internal human resources web server, which hosts normal http and https traffic. To save administrative costs, the finance and human resources are consolidated on a single HP-UX server. To prevent resource contention, they are placed on separate Apache servers residing in separate workload groups. Both are resource-intensive, but, based on the two departments' budgets, it is decided to reserve 35 shares of the server's CPU resources for the human resources traffic and 55 shares for the finance httpd traffic.
Two entirely separate Apache installations on the same server could be used for this example, but we'll assume that the same staff maintains the two Apache instances, so they would like to keep the number of separate installations to a minimum and share as much configuration information as possible between the two instances.
The human resources web server hosts normal http and https traffic, using port 80 and port 443 respectively. The finance application listens on port 800, so the URLs for it use http://mymachine:800. We assume for example purposes that there is an easy way to lead the users to the payroll application at nonstandard port 800. This could be as simple as mailing a URL with port 800 to the users to bookmark, or the end product of URL redirection from another machine, fir |
| |
