Memory in a Virtual Environment
Similar to CPU resources, the performance of the gateway depends heavily on memory that is allocated to the Virtual Appliance. Memory configuration directly impacts both data throughput and message size capabilities. It is important to allocate memory correctly to achieve reasonable performance.
gateway83
Similar to CPU resources, the performance of the
CA API Gateway
depends heavily on memory that is allocated to the Virtual Appliance. Memory configuration directly impacts both data throughput and message size capabilities. It is important to allocate memory correctly to achieve reasonable performance.Memory Allocation
The following factors directly affect memory usage on the
CA API Gateway
:- Service policy composition:Assertions that create copies of messages within memory consume more memory. Examples are assertions that deal with: XSLT transformation, schema validation, creation of variables.
- Available processing threads:You can increase the number of threads available to the Gateway for message processing. This allows the Gateway to handle more message traffic under load. If you do this, memory usage increases as all messages are stored in memory while being processed.
- Message size:Larger messages increase memory demand.
When configured with 2/3 of available memory for the Java Virtual Machine (JVM), the ideal memory configuration for the Virtual Appliance is 8 GB. With 8 GB of memory, the Virtual Appliance using default values should be able to handle message sizes up to 100 MB at minimum, processing at gigabit or faster speeds. This should be adequate for most traffic situations.
For smaller messages (1 MB and under), you can get nearly identical performance with 4 GB of memory. This is beneficial if you have limited memory on the host or if you do not want to allocate too much resource to any one image. (Note that performance suffers if a significant number of large messages traverse a 4 GB image.)
Memory Reservation
CA Technologies strongly encourages using memory reservation and high share allocation for Virtual Appliances, both in performance and production environments. The reason lies in how the Virtual Appliance uses memory and how memory is allocated to the Java Virtual Machine (JVM). The Gateway process uses memory as required. Unused memory is not returned to the OS, instead the Gateway keeps it for its own processes. Any memory management that is performed by the hypervisor can interfere with the Gateway’s own memory management. This affects performance negatively.
If memory is not reserved, the Virtual Appliance may exhibit inconsistent (but not necessarily poor) performance. The following potential issues may also arise:
- The Virtual Appliance is designed to use up to 2/3 of the available memory heavily (with the JVM), but the remaining 1/3 lightly. When over-commitment occurs, the hypervisor reclaims and re allocates memory from the Virtual Appliance to other images as needed. The final part of the memory re-allocation steps involves swapping to disk, which impacts performance significantly.
- If the hypervisor host is hosting images with memory allocations greater than the physical memory available, memory reallocation occurs more often.
Performance is the most consistent when the Virtual Appliance has access to 100 percent of the memory that is allocated to it. The next best option is reserving memory that is allocated to the JVM. For example, if 8GB of memory is given to the image, the ideal situation is to reserve the full 8 GB of memory for the image. If that cannot be done, then attempt to reserve 6 GB of the memory. The JVM is giving 5.5GB of the available memory and the 6 GB reservation covers at least that amount.