How does using memory mapped shared libraries affect performance and memory usage ?

How does using memory mapped shared libraries affect performance ?
What are memory mapped shared libraries ?
How will the introduction of memory mapped shared libraries affect performance benchmarks ?
How does using memory mapped shared libraries affect memory allocations & usage ?
 

What are memory-mapped procedure libraries ?

Memory-mapped procedure libraries are an extension to the procedure library functionality. 

• Memory-mapping a library allows it to be loaded into shared memory segments.
• The purpose is to improve scalability on systems where multiple client processes are running the same set of r-code by cutting down sytem-wide memory costs: The clients can access and execute the same r-code segments in shared memory as opposed to each client managing their own copy. 
• This can help maintain good performance as the number of client processes increases. As the main benefits are seen on machines that run multiple client processes, this mostly benefits terminal servers (either *nix servers hosting character sessions, or Windows terminal servers) and machines running classic AppServer/WebSpeed brokers.

For further details on building, maintaining and deploying procedure libraries refer to Article:

•  Why and how to use a procedure library  

The Pacific/Progress AppServer for OpenEdge (PASOE), introduced in OpenEdge 11.5 will not see much benefit in using memory-mapped libraries over standard libraries. This because instead of using multiple agent processes, it uses multiple worker threads within a single process. The r-code is a shared resource between these worker threads no matter how it's deployed.

How will Memory-mapped libraries impact performance tuning, in more detail ?

Keep in mind: In the world of performance tuning, there are no silver bullets. Each change made needs the benchmark tests to be analysed as to their effective execution of the change and then analysed as to their impact.

There are a few points to note:

1. Memory-mapped libraries will be slightly larger than standard libraries. In most cases this isn't significant, but it may matter in cases where keeping minimum footprint is critical.
2. Memory-mapped libraries are initially loaded and mapped by a RUN statement, then are unloaded when the last client session that opened it has exited. From a situation where no clients are running (example, an AppServer that had all agents trimmed) the first client session can be slower due to extra overhead in mapping the file to memory on the OS level. Further clients should be faster as they'll get the existing handles from the OS. 
3. There may be OS kernel and permission settings that need to be reviewed, to assure the client sessions actually have access to the shared memory segments, and to make sure they can be loaded within the OS limits.
4. Memory-mapped libraries must fit into the Virtual Address Space of the client process in their entirety. This can be an issue with 32-bit clients, which have only 2GB address space. Particularly when the clients use shared memory database connections, where the database's buffer pool imposes the same restriction

To assess the performance impact of Memory-Mapped libraries:

There are 3 major players in the field: CPU Overload, Memory Swapping and Disk Speed.

Specific points to look for:

1. Did overall memory utilization decrease or increase?
2. What was the difference in I/O?
3. What's the difference in CPU utilization ?

How to create a memory-mapped library ?

Memory-Mapped libraries are created with the PROLIB tool:

• First, build a standard procedure library (.pl) outlined in Article  Why and how to use a procedure library   
• Then build the memory-mapped library from the standard one using the command: 
  $   prolib <library name> -makeshared <mapped library name>

How to deploy a memory-mapped library ?

Memory-mapped libraries are deployed in the same way as regular procedure libraries, by including them on the PROPATH for the clients. 

• They must be stored on disk in a folder accessible by the client executable.
• Configure the application's registry key or .ini file to reflect the same application PROPATH

How to add / replace / delete files in a memory-mapped library ?

This cannot be done directly. The modifications must be made on the standard library, after which the memory-mapped version must be re-created.

References to Other Documentation:

OpenEdge Deployment: Managing ABL Applications, sections 'Managing Client Performance' and ''Managing Procedure Libraries'

Progress Article(s):
 Why and how to use a procedure library
 Can I stop excessive AppServer memory consumption by moving large pieces of R-code into a shared memory procedure library?