This documentation is for WSO2 Application Server 5.2.0. View documentation for the latest release.
Performance Statistics of Lazy Loading - Application Server 5.2.0 - WSO2 Documentation
||
Skip to end of metadata
Go to start of metadata

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 standalone Application Server instance and a request was issued to 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 the memory usage were obtained using the JMX console as follows, using a graph that depicts the memory usage of service artifacts with lazy loading:

Service lazy loading statistics

Lazy Loading of Tenants

A simple service was deployed in a tenant and a request was issued to it. Then the tenant was left to idle so that it was cleaned from the AxisConfiguration. After the tenant got cleaned, a 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, using a graph that depicts the memory usage of tenants with lazy loading:

Tenant lazy loading statistics

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

  • No labels