WASD Features and Facilities

11.Server Performance

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.

The test-bench system was an DEC PWS 500 with 1 CPU and 1.5GB memory, running VSI OpenVMS V8.4-2L1 and VSI TCP/IP TCPIP V5.7-13ECO5F.

This performance data (WASD v11.5) has been collected very differently to the next most recent from over a decade ago (WASD v10.0). Apart from the move from an HP rx2600 to the vintage PWS 500, the previous benchmarking tools were WASD-in-house, ApacheBench (AB) and WASDbench (WB), executing on the same system as the server, eliminating network traffic on-the-wire. The current absolute benchmarks cannot meaningfully be compared to previous data. The relativities seem to be comparable.

Benchmark Setup

These 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 is running on a an 8CPU 32GB Mac Pro, across a 500 Mbps LAN to the 100 Mbps interface of the PWS. The obvious resource constraints are the single PWS CPU and network interface. Every effort has been made to ensure these do not unreasonably constrain the comparison.

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 1.1.1 and negotiated TLS v1.2.

Output from h2load benchmarking runs are included in the WASD_ROOT:[EXERCISE]*V115*.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 execute at the same process priority, access logging and host name lookup disabled, and runs on the same machine in the same relatively quiescent environment. 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 v11.5 is present on ports 80 and 443.

Apache Comparison

The Apache comparison used the latest VSI AXPVMS CSWS V2.4-38C (based on Apache v2.4.38) kit. Apache is present on ports 7780 and 7443.

OSU Comparison

Previous benchmarking included OSU data. These are no longer collected.

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 (non-relevant output snipped):

• WASD_ROOT:[EXERCISE]PERF_FILES_V115.TXT

File Transfer Rate

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

Data file (non-relevant output snipped):

• WASD_ROOT:[EXERCISE]PERF_XFER_V115.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 (non-relevant output snipped):

• WASD_ROOT:[EXERCISE]PERF_SCRIPTS_V115.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.