Scalability by Design
Scalability by Design
The Lambdacode framework is designed to scale by configuration change.
Theoretically, the system can scale to utilise the resources of the host platform, to the limit of the underlying JVM and mySQL database.
This is achieved by using a combination of connection pools and middleware object design.
The middleware object design ensures that the JVM size is not any multiple of the concurrent user count.
To ensure that the various data operation types do not block each other under load, there are connection pools for each type, and the number of connections per pool is configurable. If the configuration is changed, the J2EE application must be restarted.
For example, users enagaged in data input use one connection pool, users engaged in row editing use another, and users querying data, another.
Or how to tune your application connection pools for increased performance under load.
Edit your CATALINA_HOME/webapps/PROJECT_NAME/WEB-INF/web.xml file.
Navigate to the SCALABILITY section in your text editor :
Change the size of the connection pools.
| Pool Parameter | Purpose |
|---|---|
| sizeOfSecurityDBConnPool | Dedicated connection to the JGSEC security database for user access validation |
| sizeOfFieldListDataPool | Dedicated connection that is used to build or re-build list contents for SELECT or RADIO fields |
| sizeOfRowUpdatePool | Dedicated connection for row update functions |
| sizeOfRowSelectPool | Dedicated connection for row select for edit functions |
| sizeOfDeleteProcPool | Dedicated connection for row delete functions |
| sizeOfInsertProcPool | Dedicated connection for row insert functions |
| sizeOfDBViewPool | Dedicated connection for row view functions, as well as search result display |
| sizeOfReportPool | Dedicated connection for report data |
| sizeOfRowSealPool | Dedicated connection for the row seal function |
| Usage Scenario | Effective Change |
|---|---|
| user load is predominantly data capture |
increase the connection count of sizeOfInsertProcPool increase the connection count of sizeOfDBViewPool |
| you have many lists derived from tables, whose source data is often added to or modified | increase the connection count of sizeOfFieldListDataPool |
| user load is predominantly data update |
increase the connection count of sizeOfRowSelectPool increase the connection count of sizeOfRowUpdatePool increase the connection count of sizeOfDBViewPool |
| user load is predominantly data search | increase the connection count of sizeOfDBViewPool |
| a large user concurrency | increase the connection count of sizeOfSecurityDBConnPool |
Connection pools that do not need multiple connections :
| Connection Pool | Reason |
|---|---|
| sizeOfRowSealPool | One connection should cater for several hundred concurrent users each marking rows as sealed, a condition that may never occur in practice |
The system stores database performance metrics. By analysing the database repsonse times, it may be determined when to increase the pool sizes.
Normal database transaction times are single digit milliseconds when the Tomcat Server and mySQL server are on the same host.
When transaction times exceed double-digit milliseconds, performance may benefit by increasing the relevant connection pool sizes.
Scalability by Design
