Many performance optimizations in EAServer use caching: once created, objects such as component instances and database server connections are pooled for reuse, avoiding the overhead of re-creating the object. EAServer also caches servlet responses and static HTTP pages to avoid the overhead of running the servlet or reading files from disk, respectively. Caching reduces response time at the expense of increased memory use.
To maximize the performance gain from caching, Sybase recommends you run EAServer with as much memory as possible, from 1GB minimum for large deployments up to the limit of the machine architecture (4GB on most 32-bit address systems).
Common performance problems related to memory use include:
Memory leaks A memory leak occurs when code creates dynamically allocated objects but never releases them. In a Java or EJB component, you must set object references to null to release the memory associated with them. When using JDBC connections, you must release statement objects before releasing connections back to the connection cache (see “Clean up connections before releasing them to the cache”). Since EAServer pools and reuses component instances and connection caches, a memory leak can slowly exhaust the available memory. You can diagnose and find memory leaks using a profiling tool—see “Profiling software”.
Swapping Most operating systems support some form of virtual memory, which allows programs to address more memory than is physically available on the machine. Excess memory is mapped to data stored on disk. Swapping occurs when the system exchanges in-memory data for data stored on disk. Swapping should be avoided since the resulting disk I/O slows down the server. Memory leaks can cause swapping. If you have eliminated memory leaks, you can avoid swapping by ensuring that the machine has enough memory to support the EAServer configuration, and by making sure the system’s per-process memory limit allows the server to use all of it. If you cannot increase physical memory, reduce the server’s memory requirements by adjusting the parameters listed in “EAServer memory requirements”.
Object churning Large, complex objects such as EJB components and database connections can take considerable time to allocate and construct. Object churning refers to repeated allocation and deallocation of the same object. For components, use instance pooling to avoid this phenomena, as described in “Instance pooling”. For database connections, use a connection cache. You can cache objects of other types within your component, servlet, or JSP class instance.
