Developer Blog |
We want to constantly improve our product's scalability, and our partnership with IBM helps drive this aim forward. The last week of January saw software engineers from Appway visit the IBM Innovation Center in Zürich for the fourth time. Focused on testing the scaling capabilities of the Appway Platform, the results confirmed our expectations.
This post covers the main tests we ran: to investigate whether more nodes could handle a larger load. The load was kept constant, while the number of Appway nodes increased. The tests were run using the Swimworld v1.3.1 solution with 600 concurrent users. Each user had 20 processes running, and a value store size of 64kB. The process length was 5, where "process length" in the context of the Swimworld describes the average number of clicks on "Repeat" on the Screens "Swim1" and "Swim2".
Swimworld 1.3.1
We used one of the standard Appway test solutions, called "Swimworld", to simulate a process in which we can influence the process duration, and the size of the value store.
The model is very simple. It is composed of 2 Process objects ("Portal", and "Swim" with 2 swimlanes) and 3 Screen objects ("Portal", "Swim1", and "Swim2"). The "Portal" Process displays three worklists, plus a button, from which the user can start instances of the "Swim" Process. In the Swim1 Screen, the user defines a message and sets the size of the value store. This step can be repeated n times before moving on to a second user in the other swimlane. The second user sees the content inputted by the first user and can repeat the task or end the process.
In both swimlanes, the amount of repetitions influences the process length (each loop takes an average of 7.5 seconds). Each repetition updates the value store.
Download the "Swimworld" solution (version 1.3.1, for Appway 6.0 and greater): Swimworld v1.3.1
Hardware
Here's the hardware set-up we used:
• 3 physical IBM Blade servers, each with 24 cores (6 CPUs with 4 threads each)
• 2 VMWare virtual machines on each Blade; each virtual machine had 8 cores and 16GB of main memory
• Each virtual machine ran one installation of Appway 6.1.8
• Cluster storage was provided by a relational database located on a separate Blade server
Software
• Virtual machines OS: Red Hat Linux
• Cluster storage: IBM DB2 AWSE 10.5.0.3
• Application server: IBM WebSphere ND 8.5.5.3
• IBM JDK 7
• Appway 6.1.8
Results
We started the tests with one node — and, as expected, the system was not able to handle the load. After adding a second node, the system could handle the load, but we detected problems when it came to the two nodes sustaining such a high load over time.
With three nodes, the system could handle the load fully, and sustainably: CPU usage was 55%, and response times were around 60 ms.
The tests using four, five and six nodes demonstrated an increasingly responsive system in relation to the number of nodes, as well as a constant and consistent reduction in CPU usage.
Conclusion
The results we gained from these tests show that Appway 6 scales with the number of nodes in a cluster. More nodes help to distribute CPU usage, and therefore reduce the individual CPU load per node. To some extent, a lower CPU load also improves response time.
We're looking forward to visiting the Research Labs again in April 2015 to run further tests, so stay tuned!
---
Disclaimer: Test results were achieved using specific computer systems and solutions. Any difference in system or solution design or configuration may affect the actual performance. The results provide a benchmark for testing purposes only. Such results should not be used for sizing requirements.
This post covers the main tests we ran: to investigate whether more nodes could handle a larger load. The load was kept constant, while the number of Appway nodes increased. The tests were run using the Swimworld v1.3.1 solution with 600 concurrent users. Each user had 20 processes running, and a value store size of 64kB. The process length was 5, where "process length" in the context of the Swimworld describes the average number of clicks on "Repeat" on the Screens "Swim1" and "Swim2".
Swimworld 1.3.1
We used one of the standard Appway test solutions, called "Swimworld", to simulate a process in which we can influence the process duration, and the size of the value store.
The model is very simple. It is composed of 2 Process objects ("Portal", and "Swim" with 2 swimlanes) and 3 Screen objects ("Portal", "Swim1", and "Swim2"). The "Portal" Process displays three worklists, plus a button, from which the user can start instances of the "Swim" Process. In the Swim1 Screen, the user defines a message and sets the size of the value store. This step can be repeated n times before moving on to a second user in the other swimlane. The second user sees the content inputted by the first user and can repeat the task or end the process.
In both swimlanes, the amount of repetitions influences the process length (each loop takes an average of 7.5 seconds). Each repetition updates the value store.
Download the "Swimworld" solution (version 1.3.1, for Appway 6.0 and greater): Swimworld v1.3.1
Hardware
Here's the hardware set-up we used:
• 3 physical IBM Blade servers, each with 24 cores (6 CPUs with 4 threads each)
• 2 VMWare virtual machines on each Blade; each virtual machine had 8 cores and 16GB of main memory
• Each virtual machine ran one installation of Appway 6.1.8
• Cluster storage was provided by a relational database located on a separate Blade server
Software
• Virtual machines OS: Red Hat Linux
• Cluster storage: IBM DB2 AWSE 10.5.0.3
• Application server: IBM WebSphere ND 8.5.5.3
• IBM JDK 7
• Appway 6.1.8
Results
We started the tests with one node — and, as expected, the system was not able to handle the load. After adding a second node, the system could handle the load, but we detected problems when it came to the two nodes sustaining such a high load over time.
With three nodes, the system could handle the load fully, and sustainably: CPU usage was 55%, and response times were around 60 ms.
The tests using four, five and six nodes demonstrated an increasingly responsive system in relation to the number of nodes, as well as a constant and consistent reduction in CPU usage.
Conclusion
The results we gained from these tests show that Appway 6 scales with the number of nodes in a cluster. More nodes help to distribute CPU usage, and therefore reduce the individual CPU load per node. To some extent, a lower CPU load also improves response time.
We're looking forward to visiting the Research Labs again in April 2015 to run further tests, so stay tuned!
---
Disclaimer: Test results were achieved using specific computer systems and solutions. Any difference in system or solution design or configuration may affect the actual performance. The results provide a benchmark for testing purposes only. Such results should not be used for sizing requirements.
Comments (0)
Developer is transitioning to Appway Community
The next step in the transition to community.appway.com is here! As of April 2017, the Community Blog is exclusively available via community.appway.com. The Blog joins the Forum and our Support system, which already moved to their new home in 2016.
Our written material (recipes and documentation) is currently being migrated, and is available in beta on community.appway.com at Support > Knowledge Base.
All information for Appway 6.3 and below is still available here on developer.appway.com while this migration takes place.
Note: Material relevant for Appway 7 will only be available in the Knowledge Base on community.appway.com
Any questions or feedback? Please contact community@appway.com
Our written material (recipes and documentation) is currently being migrated, and is available in beta on community.appway.com at Support > Knowledge Base.
All information for Appway 6.3 and below is still available here on developer.appway.com while this migration takes place.
Note: Material relevant for Appway 7 will only be available in the Knowledge Base on community.appway.comAny questions or feedback? Please contact community@appway.com