When running the profile-creator script it will create a zip file containing the new distribution. However, the script assumes a folder name, in this case wso2ei-6.3.0-SNAPSHOT, to look for the content. You can either change the <EI_HOME> folder name, or the script where it sets the ‘DISTRIBUTION’ environment variable to match the other and then it works like a charm.
So, what does this mean for size? When you download the Enterprise Integrator and unzip it, it sits at a nice 910 MB. The Integrator profile already shrinks to 524 MB while the Micro Integrator profile ends up sitting pretty at 426MB.
Figure 2 Disk Usage per Profile
That is not a huge difference between the Integrator and the Micro Integrator profiles, I assume that is mostly because the core functionality remains the same. It is a still a fully functional ESB and DSS, however the features it loses are non-essential and do eat up resources when running.
Features not present in the Micro Integrator are:
- Built-in Clustering
- Management Console
- Deployment-Sync
- Hot Deployment
After creating the different profiles, it is time to put the Micro Integrator to the test. When starting the Micro Integrator, it took on average 6 seconds to start, where the Integrator took an average of 23 seconds. Clearly a significant increase.
When we look at the memory usage using JConsole to connect to the processes we see the Micro Integrator using a Heap Memory of up to roughly 125 Mb while the Integrator hit around 190Mb. While the lows lie just above 50Mb and 100Mb respectively. Again, a significant difference in favor of the Micro Integrator.
Figure 3 Micro Integrator Heap Memory Usage
Figure 4 Integrator Heap Memory Usage
Deploying to the Micro Integrator
Without the Management Console, the way to deploy a service on the Micro Integrator is to place your CAR file in <EI_HOME>/wso2/micro-integrator/repository/deployment/server/carbonapps/. Because there is no Hot Deployment we then have to restart our instance to actually deploy the contents of the CAR file.
Having created a simple HelloWorld API with a separate sequence (after all we want to have a look at the file based registry as well) I copied it to the appropriate folder and restarted the instance. When the CAR file is being deployed the corresponding folders for the registry are created under <EI_HOME>wso2/micro-integrator/registry. The instance still starts in roughly 6 seconds.
The default offset for the Micro-Integrator is 10, which means that without any changes I can run it next to an instance of the Integrator and test the HelloWorld API, and compare responses/response times. It also means that out of the box the HTTP listener port is 8290 instead of the regular 8280.
The first time making a GET request to the API on either instance takes roughly 120-130ms, after that both settle on values that fluctuate between 5-15ms without any significant difference between the two instances. Performance of the two profiles is comparable.
Conclusion
Micro Integrator is introduced as a server of choice if you have requirement to host specific integrations as a “microservice” and get all advantages of microservices based architecture. This will bring changes to the way we design and deploy integrations. With its smaller set of features, I feel that the Micro Integrator is not just more suitable for scalable containerized solutions, it is its only purpose. Without the Management console and the Hot Deployment it is hardly suitable as a traditional ESB where you can manage your services and API’s. To me the Micro Integrator seems clearly meant to be deployed as a scalable solution with a fixed (set of) service(s) per instance.
Below is a quick overview of all the measured statistics:
| Integrator | Micro Integrator | |
| Disk Usage | 524 | 446 |
| Heap Memory Usage | 100-190Mb | 50-125Mb |
| Start-up Time | 23 seconds | 6 seconds |
| Service reponse time | 10ms (average) | 10ms (average) |
*) These tests were run on an Ubuntu 17.10 Virtualbox image with 2 CPU cores and 6Gb of RAM.
If you have any questions about this blogpost contact us via the comments section below. View also our webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.
