Foreign commands for these utilities (and the HTTPD control functionality) will need to be assigned in the adminstration users' LOGIN.COM. Alternatives should be used when the environment supported through NETLIB. For example:
HTTPD == "$HT_EXE:HTTPD" !HTTPD == "$HT_EXE:HTTPD_NETLIB" HTTPDMON == "$HT_EXE:HTTPDMON" STREAMLF == "$HT_EXE:STREAMLF" WWWRKOUT == "$HT_EXE:WWWRKOUT" !WWWRKOUT == "$HT_EXE:WWWRKOUT_NETLIB"
This utility converts VARIABLE and VAR_? format files to STREAM_LF. The WASD HTTPd server access STREAM_LF files in block/IO-mode, far more efficiently that the record-mode required by variable-record format files. Use STREAMLF/HELP for some basic usage information.
NOTE This server can also be configured to automatically
convert any VARIABLE record format files it encounters to STREAM_LF.
12.2 - HTTPd Monitor
The HTTPd server may be monitored using the HTTPDMON utility. This utility continuously displays a screen of information comprising three sections:
The following example provides sample output:
Port: 8088 HTTPDMON v1.2.0 AXP (HTTPd v4.2) Friday, 20-JUN-1997 07:40:45 Process: HTTPd:8088 PID: 2048F4CC User: HTTP$SERVER Startup: 0 Exit Status: n/a (Zeroed: 0) Up: 0 14:37:14.93 CPU: 0 05:00:02.07 Pg.Flts: 2116 Pg.Used: 26% WsSize: 6768 (3384kB) WsPeak: 4960 (2480kB) AST: 15/600 BIO: 2/512 BYT: 0/135840 DIO: 0/512 ENQ: 0/600 FIL: 6/100 PRC: 8/50 TQ: 16/200 Connect: 328729 Accept: 328729 Reject: 0 Busy: 0 Current: 0 Peak: 17 Error: 0 Parse: 328733 (2 redirect) Forbidden: 0 RMS: 0 DELETE: 0 GET: 328733 HEAD: 0 POST: 0 PUT: 0 Admin: 6 Directory: 41090 File: 143816 (1) IsMap: 2 Menu: 0 Put: 0 SSI: 20544 Update: 1 DCL: 184896 CGI: 82182 CGIplus: 41090 (41090) Spawn: 41 Subproc: 8 1xx: 0 2xx: 308186 3xx: 1 4xx: 20544 5xx: 0 (0 errors) Rx: 27,947,098 Tx: 2,453,232,050 (bytes) Time: 20 07:33:04 Host: datlv.wasd.dsto.gov.au Status: 200 Rx: 95 Tx: 34477 Request: GET /ht_root/exercise/escherknot.gif
- NOTE -
Yes! This is a genuine screen capture during an extended testing period using the WWWRKOUT utility (see 12.3 - Server Workout (stress-test)) from two other VMS systems in the same cluster. One third of a million requests, and nearly of 2.5 Gigabytes transmitted in approximately 14 hours of testing on a heavily loaded, general-purpose system! Requests comprised a mixture of file transfers, SSI documents, directory listings and CGI applications. This is an average of 6.5 requests per second and transfer of 50 Kbytes per second.
The /HELP qualifier provides a brief usage summary.
This information is, in part, obtained from the following logical names:
The server counter values are carried over when a server (re)starts
(provided the system has stayed up). To reset the counters use the on-line
server administration menu (see 8 - HTTPd Server Administration).
12.3 - Server Workout (stress-test)
The WWWRKOUT (``World Wide Web Workout'') utility exercises an HTTP server, both in the number of simultaneous connections maintained and in the number of back-to-back sequential connection requests and data transfers. A native UCX image and a separate NETLIB image are provided.
This utility can be used to stress-test the WASD VMS HTTP server (or any other), or to make comparisons between it and other servers. When stress-testing a server, evaluating performance or just using it to try and break a test-bed server, it is best used from multiple, autonomous systems simultaneously.
It sets up and maintains a specified number of simultaneous connections to a server. It reads a buffer of data from each connection in turn, where data is waiting (does not block), until the document transfer is complete and the connection closed by the server. It then closes the local end and immediately reuses the now-free socket to initiate another sequence. If enabled (it is by default), the utility attempts to reflect the real-world in varying the data transfer rate for each connection, by setting the number of bytes read during each read loop differently for each connection. All transfered data is discarded.
The data transfer rate for each connection is displayed at connection close. It is by default it is the effective transfer rate, that is the rate from opening the connection to closing it, and so includes request processing time, etc. If the /NOEFFECTIVE qualifier is employed it measures the document data transfer rate only.
Although a single document path may be specified on the command line it is preferable to supply a range of document paths, one per line in a plain text file. Each document path and/or type specified should be different to the others, to exercise the server and file system cache. Any number of paths may be specified in the file. If the file is exhausted before the specified number of connections have been established the file contents are recycled from the first path. If a path or a file of paths is not specified the utility just continually requests the welcome document.
To assess a server's total throughput choose paths that lead to large documents (> 50K), where the overhead of connection setup, rule processing and transfer initiation are less significant than the data transfer itself. The buffer size variation functionality should be disabled using the /NOVARY qualifier when assessing data transfer rates. Responsiveness is better assessed using small documents (< 2K), where the overhead of the non-data-transfer activities is more significant.
WWWRKOUT [server_host_name[:port]] [path] [qualifiers]
Examples:
$ WWWRKOUT $ WWWRKOUT www.server.host "/web/home.html" $ WWWRKOUT www.server.host:8080 /FILEOF=PATHS.TXT $ WWWRKOUT /SERVER=www.server.host /PORT=8080 /NOBREAK /NOVARY /FILEOF=PATHS.TXT $ WWWRKOUT www.server.host:8080 /FILEOF=PATHS.TXT /NOEFFECTIVE /NOVARY $ WWWRKOUT www.server.host /FILEOF=PATHS.TXT /COUNT=500 /SIMUL=20 /BUFFER=512
The /HELP qualifier provides a brief usage summary.