This documentation is for WSO2 Application Server version 5.1.0. View documentation for the latest release.

Unknown macro: {next_previous_link3}
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Lazy loading is a design pattern used specifically in cloud deployments to prolong the initialization of an object or artifact until it is requested by a tenant or an internal process. The WSO2 Application Server has enhanced lazy loading support from version 4.1.2 on-wards. This feature is available in the standalone version of the product as well as in multi-tenanted, Platform as a Service deployments.

Lady loading has contributed significantly to the statistically-proven performance improvements and efficient memory usage of the WSO2 Application Server. These improvements are particularly observable in WSO2 Stratos deployments. WSO2 Stratos is the Platform as a Service offered by WSO2 for public and private cloud deployments.

Lazy loading is implemented in two levels as follows:

  • Lazy loading of tenants.
  • Lazy loading of deployment artifacts (of a tenant or a stand-alone Application Server instance.)
The lazy loading feature can be enabled via the carbon server configuration file (carbon.xml). The deployer that handles lazy loading is called GhostDeployer.  A flag to enable or disable Ghost Deployer is as follows. By default this is set to false. That is because the Ghost Deployer works only with the HTTP/S transports. If  using other transports, we don't have to enable Ghost Deployer.

 

<EnableGhostDeployer>true</EnableGhostDeployer>

When a standalone WSO2 Application Server instance is started with lazy loading enabled, its Services, Web applications and other artifacts (Jaggery apps, JAX-* webapps) are not deployed right away. They are first loaded in Ghost form and the actual artifact is deployed only when a request for the artifact is made. Also, if an artifact is not being utilized for a certain period of time, it will be unloaded from memory.

Similarly, in a cloud deployment, all tenants are not loaded at the time the Stratos services start but only when a request is made to that tenant. Also, if a tenant is not being utilized for a certain period of time, it will be unloaded from memory. Therefore, in PaaS deployments of the WSO2 Application Server, lazy loading applies both for tenants as well as a tenant’s artifacts. Therefore, for a tenant in a Cloud environment, lazy loading is applicable in both levels. As a result, the associated performance improvements and resource utilization efficiencies are optimal.

  • No labels