TL;DR WASD's scripting IPC at ~45MBps holds its own against
Apache's ~27MBps. WASD's memory buffer IPC pushes that
to ~76MBps, approximately 76% of the test LAN bandwidth.
WASD uses a detached script process model that lends itself to easy VMS'
record-oriented output, as well as to stream-oriented output. WASD's
event-driven, monolithic design constrains integrated functionality.
The solution is to execute non-core serving as detached processes created on
demand and thereafter efficiently maintained.
WASD scripting IPC uses mailboxes between the detached process and the server
process. Mailboxes are by default record oriented devices and this lends
itself to output from VMS applications and devices, importantly including
DCL. The WASD server adjusts IPC carriage-control to web expectations.
When script output requires a stream convention WASD suspends
carriage-control adjustment automatically or on script directive.
script-process -> mailbox -> server-process -> network
Memory buffer IPC allows a much larger buffer (MBs) than the mailbox 65k.
script-process -> mem-buf -> server-process -> network
VMS Apache uses a multiple process-based model. For integrated
functionality, for example Perl, PHP, Python, the scripting engine is an
image loaded into the server process(es). The engine writes directly to the
network. For CGI under VMS a script runs as a subprocess meaning the
naturally stream-oriented network connection must be switched to a
record-oriented mode. Utilities allow it to be moved between such modes.
server-process -> network
The WASD model has the flexibility of the intermediate processing of script
output, along with the overhead of the intermediate processing. In practice
it appears this processing doesn't detract from overall performance at all.
TEST ENVIRONMENT
~~~~~~~~~~~~~~~~
From the WASD Server Statistics / Environment report:
innotek GmbH VirtualBox "Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz"
with 3 CPUs and 7GB running VMS V9.2-3
X86VMS$ @kits:vups
innotek GmbH VirtualBox with 3 CPU and 7936MB running VMS V9.2-3
Approximate System VUPs Rating : 721.0 ( min: 717.0 max: 723.0 )
1Gbps LAN with cURL at the command-line on a 6 CPU 32GB macOS 15.1.
For throughput measurement the cleartext service is used, avoiding the
overhead of TLS encryption.
The VMS Apache (2.4.54, port 7780) comparison merely wraps the same memory
buffer demonstration script image with DCL.
|X86VMS$ type APACHE$COMMON:[CGI-BIN]membufdemo.com
|$ apache$dcl_env
|$ membufdemo == "$apache$root:[cgi-bin]membufdemo.exe"
|$ membufdemo
And as Apache CGI has a number of wrinkles on VMS, to provide as fair a
comparison as possible, the MEMBUFDEMO script has been built into an Apache
loadable module.
YMMV: in absolute terms but the relative performance should remain.
Note: the cURL download speeds are MEGA-BYTES-per-second.
PERFORMANCE COMPARISON
~~~~~~~~~~~~~~~~~~~~~~
Mailbox IPC:
|% curl -o /dev/null "http://x86vms.lan/cgi-bin/membufdemo?1000"
| % Total % Received % Xferd Average Speed Time Time Time Current
| Dload Upload Total Spent Left Speed
|100 1000M 100 1000M 0 0 45.5M 0 0:00:21 0:00:21 --:--:-- 43.6M
Memory buffer IPC:
|% curl -o /dev/null "http://x86vms.lan/cgi-bin/membufdemo?1000+b"
| % Total % Received % Xferd Average Speed Time Time Time Current
| Dload Upload Total Spent Left Speed
|100 1000M 100 1000M 0 0 76.0M 0 0:00:13 0:00:13 --:--:-- 74.0M
With VMS Apache:
|% curl -o /dev/null "http://x86vms.lan:7780/cgi-bin/membufdemo?1000"
| % Total % Received % Xferd Average Speed Time Time Time Current
| Dload Upload Total Spent Left Speed
|100 1000M 0 1000M 0 0 17.2M 0 --:--:-- 0:00:58 --:--:-- 18.1M
With VMS Apache loadable module:
|% curl -o /dev/null "http://x86vms.lan:7780/membufdemo?1000"
| % Total % Received % Xferd Average Speed Time Time Time Current
| Dload Upload Total Spent Left Speed
|100 1000M 0 1000M 0 0 27.2M 0 --:--:-- 0:00:36 --:--:-- 27.9M
MORE MEMORY BUFFER
~~~~~~~~~~~~~~~~~~
Eliminating the actual physical LAN by having cURL on the same x86 system
shows the further potential moving data on 10Gbps and greater bandwidth using
memory buffer.
|X86VMS$ curl -o NL: "http://x86vms.lan/cgi-bin/membufdemo?1000"
| % Total % Received % Xferd Average Speed Time Time Time Current
| Dload Upload Total Spent Left Speed
|100 1000M 100 1000M 0 0 80.5M 0 0:00:12 0:00:12 --:--:-- 79.8M
|X86VMS$ curl -o NL: "http://x86vms.lan/cgi-bin/membufdemo?1000+b"
| % Total % Received % Xferd Average Speed Time Time Time Current
| Dload Upload Total Spent Left Speed
|100 1000M 100 1000M 0 0 137M 0 0:00:07 0:00:07 --:--:-- 135M
|X86VMS$ curl -o NL: "http://x86vms.lan:7780/membufdemo?1000"
| % Total % Received % Xferd Average Speed Time Time Time Current
| Dload Upload Total Spent Left Speed
|100 1000M 0 1000M 0 0 62.8M 0 --:--:-- 0:00:15 --:--:-- 60.5M
SUMMARY
~~~~~~~
Memory-buffer provides greater throughput than mailbox. The comparison also
demonstrates that the WASD environment delivers significant bandwidth through
its script->server->network pathways. On the example class of system;
~45MBps with the default mailbox IPC and ~76MBps using the memory-buffer IPC,
approximately three-quarters of test-bench LAN bandwidth. The WASD bandwidth
is more than competitive with VMS Apache at ~17/~27MBps, even when using
vanilla mailbox IPC, but particularly when using the memory buffer.
It is also obvious that for most purposes the default mailbox IPC will be
adequate even for demanding data transfers. Memory buffer is available when
needed for the occasional exceptional application. The demonstrator can be
used to measure actual performance for a given platform, optimising MRS
against network throughput.
Demonstration code and further data available from
https://wasd.vsm.com.au/wasd_root/src/misc/membufdemo.c
https://wasd.vsm.com.au/wasd_root/src/misc/membuflib.c
This item is one of a collection at
https://wasd.vsm.com.au/other/#occasional
|