StratosLive is a Platform-as-a-Service (PaaS) offered by WSO2 and Stratos is the Cloud Middleware Platform (CMP) which powers StratosLive. It has inbuilt support for Multi-tenancy, which is a core attribute of cloud native middleware.
An important aspect of a multi-tenant cloud environment is maximum utilization of available resources, which helps fulfil many tenant needs. To achieve this task, the commonly used pattern is Lazy loading [1]. This post [2] explains how lazy loading is implemented in WSO2 Stratos. It is a recommended reading before continuing with this post.
Lazy loading is used in two ways in WSO2 Stratos. They are,
1. Lazy loading of tenants.
2. Lazy loading of tenant deployment artifacts.
Lazy loading of a tenant means that all tenants are not loaded into memory when the Stratos service starts. Each tenant is loaded only if a request is issued. Similarly, when loading a tenant, all deployed artifacts of that tenant are not loaded at once. They are first loaded in Ghost form, and only when a request is made for an artifact, the ghost will be replaced by the actual artifact. What is meant by artifacts here are services, webapps etc.
Previous releases of Stratos have lazy loading support for Services only. But from WSO2 Carbon 4.0.0 onwards, lazy loading support is added for webapps also. We have done a performance comparison for webapps with and without lazy-loading. The related post with results can be found here [3].
To ensure there are no critical issues and memory leaks, some long running tests are carried out for the following two scenarios, also keeping in mind the two ways on lazy loading mentioned above. The test was carried out using WSO2 Application Server.
Scenario 1 – Lazy loading of Service Artifact
A simple service was deployed and a request issued for it. Then the service was left to idle so that it was loaded in Ghost form by the unloader task. After it was loaded in ghost form, a request was sent again to that service. The following parameter was used in this test. This was to make sure that before the next request was sent, the service was loaded in ghost form.
The test was carried out for 08 days.
Service idle time – 1 min.
Service request interval – 3 min.
Results
The following graph is obtained through JMX Console for memory usage during the test.
ServiceLazyLoading_MemoryUsage
Scenario 2 – Lazy loading of Tenant
In this test, a simple service was deployed in a tenant and a request was issued for it. Then the tenant it self 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.
The following parameters were used in this test to make sure that the tenant was unloaded before the next request was sent to the service. The test was carried out for 05 days.
Tenant idle time – 1 min.
Service request interval – 3 min.
Results
The following graph is obtained through JMX Console for memory usage during the test.
TenantLazyLoading_MemoryUsage
Observation
We can observe from the results that in both scenarios, there are no memory leaks when lazy loading is enabled for long periods of time. According to the graphs, the memory usage is not increasing with time. It is stable.
References
[1] http://martinfowler.com/eaaCatalog/lazyLoad.html
[2] http://blog.afkham.org/2011/11/lazy-loading-deployment-artifacts-in.html
[3] http://blog.afkham.org/2012/05/lazy-loading-webapps-in-paas-deployment.html
Kishanthan's Blog 