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