TL;DR obvious profile differences in at least KERNEL mode
begs some questions about x86-64 VMS.
This item is more about X86 VMS and less about WASD but still uses WASD as a
part of the measurement process.
When running OWSP ZAP web app scanner against Alpha and x86-64 versions of
OpenVMS during WASD testing, distinctly differing profiles of CPU modes were
immediately evident. Perhaps not unexpected considering x86-64 VMS basically
emulates a 4 mode (KESU) access to memory using some sleight of hand not
required with any previous CPU architecture (VAX, Alpha, Itanium) and so is
more expensive (at least that is my lay understanding). The far more obvious
presence of KERNEL in these simple tests do beg some questions. Please
consider this post only as food for thought. The original observations were
made during the earlier reported reliability testing and then again with
WASD/Apache metrics
https://wasd.vsm.com.au/info-WASD/2023/0054
OWASP ZAP
ZAP will proceed to crawl the web application with its spider and
passively scan each page it finds. Then ZAP will use the active
scanner to attack all of the discovered pages, functionality, and
parameters.
https://www.zaproxy.org/getting-started/
ZAP is the preferred WASD site exercise and testing tool these days, and
before new versions are released, literally hundreds of thousands of 10, 20,
30 concurrent ZAP requests, are run against WASD establishing some confidence
that obvious issues are winnowed out. Of course this does not guarantee
bug-free releases :-) but does improve the chances.
https://wasd.vsm.com.au/wasd_root/wasdoc/config/#serverandsitetesting
ZAP is also used for this KERNEL mode exercise because it results in a
"crawl" of similar portions of underlying files and executables (scripts)
across multiple independent systems and so represents similar profiles of
NETWORK, SYSTEM SERVICE, APPLICATION ACTIVATION AND OTHER ASPECTS of system
behaviour.
The reference "real hardware" system was a "Digital Personal WorkStation with
1 CPU and 1536MB running VMS V8.4-2L1", rated at approximately 152 VUPs. "HP
TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 5"
The reference "hypervised hardware" system an "innotek GmbH VirtualBox with 2
CPU and 7574MB running VMS V9.2", rated at approximately 272 VUPs. "VSI
TCP/IP Services for OpenVMS x86_64 Version X6.0" To ensure as much equity as
possible the x86-64 had a second CPU disabled, making both systems
essentially single CPU.
|X86VMS$ show cpu
|
|System: X86VMS, innotek GmbH VirtualBox
|
|CPU ownership sets:
| Active 0
| Configure 0,1
Data collected using MONITOR MODES /AVERAGE and after approximately 50k
requests being processed.
| OpenVMS Monitor Utility
| +-----+ TIME IN PROCESSOR MODES
| | AVE | on node X86VMS
| +-----+ 24-APR-2023 13:02:51.05
|
| 0 25 50 75 100
| + - - - - + - - - - + - - - - + - - - - +
| Interrupt State 6 |**
| MP Synchronization |
| Kernel Mode 69 |***************************
| Executive Mode 5 |**
| Supervisor Mode |
| User Mode 17 |******
| Compatibility Mode |
| Idle Time 3 |*
| + - - - - + - - - - + - - - - + - - - - +
Now, we all know that V9.2 is an early, unoptimised release, but it needs to
be asked exactly why the very prominent value for KERNEL mode at the expense
of USER mode, compared to the Alpha below. X86 KERNEL using in excess of TWO
THIRDS the available CPU.
| OpenVMS Monitor Utility
| +-----+ TIME IN PROCESSOR MODES
| | AVE | on node KLAATU
| +-----+ 24-APR-2023 15:15:57.53
|
| 0 25 50 75 100
| + - - - - + - - - - + - - - - + - - - - +
| Interrupt State 8 |***
| MP Synchronization |
| Kernel Mode 22 |********
| Executive Mode 8 |***
| Supervisor Mode 1 |
| User Mode 47 |******************
| Compatibility Mode |
| Idle Time 14 |*****
| + - - - - + - - - - + - - - - + - - - - +
One would expect a lot more "real" work being accomplished in USER mode.
The MONITOR SYSTEM /AVERAGE doesn't reveal any huge disparities between the
two architectures, except the greater CPU consumed by the X86 VM, possibly
only reflecting the increased kernel mode used.
|Node: X86VMS OpenVMS Monitor Utility 24-APR-2023 13:04:19
|Statistic: AVERAGE SYSTEM STATISTICS
| Process States
| + CPU Busy (96) -+ LEF: 18 LEFO: 0
| |************************ | HIB: 16 HIBO: 0
|CPU 0 +--------------------------+ 100 COM: 5 COMO: 0
| |***** | PFW: 0 CUR: 1
| +--------------------------+ MWAIT: 2 Other: 0
| Cur Top: WASD:80_05E8 (22) Total: 42
|
| + Page Fault Rate (152) -+ + Free List Size (599239) +
| |*|***** | |**************** | 947K
|MEMORY 0 +--------------------------+ 500 0 +--------------------------+
| |* | | | 95K
| +--------------------------+ + Mod List Size (1091) +
| Cur Top: WASD:80_05E0 (27)
|
| + Direct I/O Rate (133) -+ + Buffered I/O Rate (349) -+
| |****** | |****************** |
|I/O 0 +--------------------------+ 500 0 +--------------------------+ 500
| | | |***** |
| +--------------------------+ +--------------------------+
| Cur Top: WASD:80_05E2 (6) Cur Top: WASD:80 (97)
|Node: KLAATU OpenVMS Monitor Utility 24-APR-2023 15:16:47
|Statistic: AVERAGE SYSTEM STATISTICS
| Process States
| + CPU Busy (87) -+ LEF: 26 LEFO: 0
| |********************** | HIB: 17 HIBO: 0
|CPU 0 +--------------------------+ 100 COM: 3 COMO: 0
| | | PFW: 0 CUR: 1
| +--------------------------+ MWAIT: 0 Other: 0
| Cur Top: TCPIP$INETACP (0) Total: 47
|
| + Page Fault Rate (329) -+ + Free List Size (69207) +
| |**|************** | |********* | 192K
|MEMORY 0 +--------------------------+ 500 0 +--------------------------+
| | | |**** | 19K
| +--------------------------+ + Mod List Size (3741) +
| Cur Top: (0)
|
| + Direct I/O Rate (219) -+ + Buffered I/O Rate (671) -+
| |*********** | |**************************|
|I/O 0 +--------------------------+ 500 0 +--------------------------+ 500
| | | | |
| +--------------------------+ +--------------------------+
| Cur Top: TCPIP$INETACP (5) Cur Top: TCPIP$INETACP (10)
Something to keep our eyes on as X86 VMS develops over time.
This item is one of a collection at
https://wasd.vsm.com.au/other/#occasional
|