How It Works

DBLX Server Memory management

On 32-bit operating systems a single table cannot exceed 1.5GB. The size of all tables cached in the database cannot exceed 2GB. If these limits are hit you have to move to a 64-bit environment for the DB to be able to grow larger.
On 64-bit operating systems a single table cannot exceed 2GB unless some different startup values are specified. The size of all tables cached in the database cannot exceed the amount of installed RAM.
Lots of RAM helps DBLX more than multiple cores, multiple processors, or high clock rates. Disk performance does not impact DBLX at runtime. The only disk consideration is that you should
put DBLX on a physical drive (as opposed to a thumb drive or a network drive) and you should have lots of free space so that the O/S does not slow down.
We have run DBLX in Andriod 2.2 with 512MB memory, saving db files to 2MB internal storage and/or a 4MB SD Card. It works fine in this configuration.
We also run DBLX on a 12GB Windows Server as well as a 2GB Mac OS/X server.
Trust the app and the virtual machines to handle this for you and handle it well.


DBLXClient Memory management

Results of a query are returned to clients fully materialized. This means that if you execute a select query that returns 100 rows, the data comprising the 100 rows will be in memory on the client side.
Its difficult to query so many rows that the client cannot handle them, but if memory was extremely low it is theoretically possible.
Note that when you run DBLX in embedded mode there is no client involved, so none of this is an issue.


DBLX Multi-user support

We have tested DBLX with up to 50 clients, and it works fine.
Since DBLX is targeted for a wide-range of memory sizes one should not expect enterprise-class client support.
Oracle and DB2 can handle thousands of clients. We don't think DBLX will perform as well as Oracle and DB2 with thousands of clients.
As the number of clients hitting the DBLX server starts to go above 50, the time it takes to perform WRITE operations starts to go up to a point that users may notice.
For example, you may insert 10 rows while 5 other clients are in the middle of WRITE operations on the same table. With <10 clients the WRITEs will appear to happen immediately. With 50 or more clients you may see those same WRITEs take 1 or 2 seconds longer.