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

Performance Statistics of Lazy Loading

WSO2 has carried out a performance comparison of the initial response times when the number of artifacts deployed in the WSO2 Application Server increases, with and without ghost deployment (GD) enabled. The test was initiated with 1 deployed artifact and gradually increased to 300.

Given below is a graphical view of the test results.

Lazy loading statistics

  • Initial response time: The response time seen by a client when a tenant is not loaded.
  • The number of artifacts: The number of artifacts deployed under that tenant.

As depicted in the diagram, without ghost deployment, the initial response time steadily increases, eventually resulting in client timeouts.

The following tests were carried out to observe the stability and consistency of memory usage and to ensure smooth operation of load balancing.

Lazy Loading of Service Artifacts

A simple service was deployed in a stand-alone Application Server instance and a request was issued for it. Then the service was left to idle so that it would be loaded in Ghost form by the unloader task. After it was loaded in ghost form, a request was sent again to that service. To ensure that the service was loaded in ghost form before sending the next request, the following parameters were used.

  • Service idle time – 1 min.
  • Service request interval – 3 min.

The test was carried out for 8 days and statistics on memory usage were obtained using a JMX Console as follows:

Service lazy loading statistics

Figure: Memory usage of service artifacts with lazy loading

Lazy Loading of Tenants

A simple service was deployed in a tenant and a request was issued for it. Then the tenant was left to idle so that it was cleaned from the AxisConfiguration. After the tenant got cleaned, the request was sent again to the service. To ensure that the tenant was loaded in ghost form before sending the next request, the following parameters were used.

  • Tenant idle time – 1 min.
  • Service request interval – 3 min.

The test was carried out for 5 days and statistics on memory usage were obtained using a JMX Console as follows:

Tenant lazy loading statistics

Figure: Memory usage of tenants with lazy loading

In both test scenarios, the memory usage is depicted as stable according to the graphs. It is not increasing with time. Also, no memory leaks were observed when lazy loading was enabled for long periods of time.