Review API ML content in v2 doc (zowe#2057)

* Update error code messages Signed-off-by: at670475 <[email protected]> * Add performance section to VSAM solution Signed-off-by: at670475 <[email protected]> * refactor VSAM performance Signed-off-by: Andrew Jandacek <[email protected]> * minor language refactor Signed-off-by: Andrew Jandacek <[email protected]> Co-authored-by: Andrew Jandacek <[email protected]> Signed-off-by: Pablo Hernán Carle <[email protected]>
pablocarle · Mar 4, 2022 · 03af5d9 · 03af5d9
1 parent 417961f
commit 03af5d9
Show file tree

Hide file tree

Showing 2 changed files with 704 additions and 656 deletions.
diff --git a/docs/extend/extend-apiml/api-mediation-vsam.md b/docs/extend/extend-apiml/api-mediation-vsam.md
@@ -5,6 +5,7 @@ describes how to configure your storage solution for VSAM. Configuring VSAM ensu
 
 - [Understanding VSAM](#understanding-vsam)
 - [VSAM configuration](#vsam-configuration)
+- [VSAM performance](#vsam-performance)
 ## Understanding VSAM
 
 `Virtual Storage Access Method (VSAM)` is both a data set type, and a method for accessing various user data types.
@@ -34,5 +35,34 @@ Configure VSAM as a storage solution through the Caching service by modifying th
 
   The character encoding. The default value is IBM-1047.
 
+### VSAM performance
+
+Accessing VSAM via java results in a performance limitation. The VSAM solution has been tested in a few scenarios.
+
+The following sequence describes the test process: 
+1. Load 1000 records into the cache concurrently (5 threads).
+2. Update all records for 120 seconds with increasing the thread count, up to `<x>` amount of threads.
+3. Read all records for 120 seconds with increasing the thread count, up to `<x>` amount of threads.
+4. Read and update all records for 120 seconds with increasing the thread count, up to `<x>` amount of threads.
+5. Delete all loaded records from the cache concurrently (5 threads).
+
+Tests were run with 3 scenarios:
+- Low load: 5 threads 
+- Medium load: 15 threads
+- High load: 50 threads
+
+Test subjects:
+- Single Caching Service with VSAM storage
+- Two Caching Services with shared VSAM storage
+
+Results:
+- The most important operation is `READ`.
+- Two Caching Services achieve better `READ` performance than a single Caching Service.
+- Based on data from the testing results, the `READ` performance appears to be acceptable, ranging from 300 ms to 1000 ms.
+- With two Caching Services and a high load, `READ` performance significantly increased.
+- Response times of other operations are also acceptable, yet error rates increase with higher concurrency.
+- Two Caching Services produce higher load on shared resource (VSAM) and have higher error rate.
+- VSAM implemetation appears to be sufficient for user-based workloads. For light automation workloads VSAM implementation appears to be acceptable as well. For heavy workloads this implementatin may not be sufficient. 
+- VSAM does not scale well beyond 1000 RPM on a node.