Performance and Scalability Benchmarks
This section maintains benchmarks for performance, scalability and security implications to gauge availability, performance of different Fineract Sub-systems.
In wide variety of Performance and Scalability Studies conducted over last 5 years, following are the aspects reported:
In a 2015 study, it has been found that:
Platform can support over 3000 virtual users on a single server with mean login times under 2000ms.
Platform's client management easily supports 3000 users while accessing client profile from 4,910,000 clients in the clients management system
Platform's client management easily supports 3000 users while accessing loan profiles from 20M loans in the LMS module
Platform can handle 2800 concurrent repayments with mean response time of 3500ms.
Given sufficient database resources and efficient load balancing, platform can scale linearly as one adds additional servers to a cluster.
In a 2017 study, it has been found that:
The platform when run by 1500 users executed 8.8 throughput(requests processed per second by the test server) with a Std. deviation of 14538.84 and an error margin of 39.73% for one user.
Further, the study suggests that 1332.2 bytes of average date of the application is a generic output with 11.52 KB/sec of application data.
It is also reported that of the 1500 HTTP requests, 904 are OK, 570 timed out and 19 were Reset by the platform. Remaining are reported as multiple type of errors such as 443: failed to respond.
Conclusive Remarks: Overall, there is a clear need to increase the performance and scalability of the Fineract Platform more so for specific use cases, where there is a high frequency operation getting executed over a short period of time. E.g payment processing use case.
For standard lending scenarios, the above studies and multiple experiences of case studies of partner Financial Institutions support a strong view of Fineract’s scalability & performance strength.
Deployment Concerns and consolidated notes including those of community conversations:
Most of the issues can be easily addressed through a combination of code level changes on the login API's of Fineract 1.x and deployment configurations. Few noted challenges are:
Client facing services need to be scaled independently of back-office facing services. E.g Customer Relationship Management(CRM) capabilities should be scaled independently while keeping transaction processing capabilities and their performance oriented scaling separate.
The client-facing services should cache all lookup data fetched from the Core banking system(CBS) including but not limited to its meta data.
Ability to route read traffic to a cluster of Fineract 1.x servers talking to replicated databases to ensure that the traffic to the cluster serving the back-office services is kept to a minimum and remains largely unaffected by increase and decrease in computing usage or simple usage traffic.
Ability to easily monitor and audit client-self service by an auditability matrix through a consolidated login authentication at Fineract 1.x platform access level.
Security implications:
While most of the issues can be easily addressed through a combination of code level changes and modifications on the login API's of Fineract 1.x and its deployment configurations, few noted challenges are:
Ability to expose the Core banking system services such as transaction processing outside of VPN or inherent and underlying tech infrastructure
It is worth noting that the security requirements of external facing services such as CRM levels are radically different from those of a CBS and vary from use case to subset of each use case. E.g The borrower relationship involving the notification mechanism vis a vis the auditable and non penetrable transaction records of the same borrower have different security standards applicable to them.
Last updated
