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.