WASD Features and Facilities

11.Server Performance

These Are v12.3 X86 Results

The server has a single-process, multi-threaded, asynchronous I/O design. On a single-processor system this is the most efficient approach. On a multi-processor system it is limited by the single process context (with scripts executing within their own context). For I/O constrained processing (the most common in general Web environments) the AST-driven approach is quite efficient.

Benchmark Setup

VMS V9.2-2 with VSI TCP/IP Services for OpenVMS x86_64 Version X6.0 on an 8 core "Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz".

The data have been collected using the h2load utility (https://nghttp2.org/documentation/h2load.1.html) from the HTTP/2 C Library (https://nghttp2.org). This utility can be used to configurably load HTTP, HTTPS and HTTP/2 servers. Note that the number of client threads (-t) is explicitly set to the connection concurrency (-c) to maximise h2load processing. The h2load utility maintains connection persistence between HTTP/1.1 requests so the network connection setup is generally only a factor for the first of many.

The h2load utility is running on a 6 core Intel Core i7 3.2 GHz 16GB Mac Mini, across a 1Gbps LAN to the Dell.

Shell scripts for h2load benchmarking runs are included in the WASD_ROOT:[EXERCISE]PERF*. directory.

Clear text HTTP (port 80) data is collected to measure internal server processing without the CPU-intensive overhead of encryption. Encrypted HTTP (port 443) data provides more real-world scenarios (especially now clear-text is largely deprecated). Both WASD and Apache were using OpenSSL 3.n and negotiated TLS v1.3.

Output from h2load benchmarking runs are included in the WASD_ROOT:[EXERCISE]PERF*1230*.TXT directory and is summarised below.

These results are indicative only!

Every endeavour has been made to ensure the comparison is as equitable as possible. Both servers run on the same machine in the same relatively quiescent environment, access logging and name lookup enabled. Each test run was interleaved between each server to try and distribute any environment variations. Those runs that are very high throughput use a larger number of requests to improve sample period validity. Both servers were configured pretty-much "out-of-the-box", minimal changes (generally just enough to get the test environment going). Multiple data collections have yielded essentially equivalent relative results.

For the test-bench WASD v12.3 is present on ports 80 and 443.

Apache Comparison

The Apache comparison used the latest VSI X86VMS APACHEWS V2.4-62.

Apache is present on ports 7780 and 7443.

11.1Simple File Request Turn-Around

A series of tests using batches of accesses. The first test returned an empty file measuring response and file access time, without any actual transfer. The second requested a file of 64k characters, testing performance with a more realistic load. All were done using one and ten concurrent requests.

Data file (extraneous output snipped):

• WASD_ROOT:[EXERCISE]PERF_FILES_1230.TXT

File Transfer Rate

Requests for a large binary file (1.6MB - 3281 blocks) indicate a potential transfer rate of multiple tens of Mbytes per second.

Data file (extraneous output snipped):

• WASD_ROOT:[EXERCISE]PERF_XFER_1230.TXT

File Record Format

The WASD server can handle STREAM, STREAM_LF, STREAM_CR, FIXED and UNDEFINED record formats very much more efficiently than VARIABLE or VFC files. With STREAM, FIXED and UNDEFINED files the assumption is that HTTP carriage-control is within the file itself (i.e. at least the newline (LF), all that is required required by browsers), and does not require additional processing. With VARIABLE record files the carriage-control is implied and therefore each record requires additional processing by the server to supply it. Even with variable record files having multiple records buffered by the HTTPd before writing them collectively to the network improving efficiency, stream and binary file reads are by Virtual Block and are written to the network immediately making the transfer of these very efficient indeed!

11.2Scripting

A simple performance evaluation shows the relative merits of WASD scripting and Apache in CGI and persistent environments, using WASD_ROOT:[SRC.CGIPLUS]CGIPLUSTEST.C which executes in standard CGI, CGIplus and Apache loadable module environments. CGIplus and Apache modules are somewhat analagous. A series of accesses were made. The first test returned only the HTTP header, evaluating raw request turn-around time. The second test requested a body of 64k characters, again testing performance with a more realistic load.

Data file (extraneous output snipped):

• WASD_ROOT:[EXERCISE]PERF_SCRIPTS_1230.TXT

Persistent Scripting

CGI scripting is notoriously slow (as above), hence the effort expended by designers in creating persistent scripting environments - those where the scripting engine (and perhaps other state) is maintained between requests. Both WASD and Apache implement these as integrated features, the former as CGIplus/RTE, and in the latter as loadable modules.

The CGIplus and Apache module data from the above CGIPLUSTEST.EXE table show the benefits of having scripts persist, reducing activation latency, thereby increasing throughput, and potentially retaining state, including the scripts themselves in local caches. Both WASD and VMS Apache use their respective persistence technologies to provide common scripting environments, including Perl, PHP and Python.

The WASD CGIplus/RTE technology used to implement its persistent scripting environments are available for general use and based on CGI principles offer a ready adaptation of well-known principles. Most site-specific scripts can also be built using the libraries, code fragments, and example scripts provided with the WASD package, and obtain similar efficiencies and low latencies. See WASD Scripting Environment document.