This is the same process as is used to determine how many elevators are required to service an office or apartment building. The objective is to "adjust" the contents of the set X such that the MPR is maximized while the impact on any particular component of X is still acceptable. Given a set of "leavings" (processes/jobs) X the "multiprogramming ratio" is the ratio between the elapsed time taken to run all the components of X side-by-each (concurrently) vs one-after-each (serially). This is called the "Multiprogramming Ratio". The objective of "Performance Management" is to obtain maximize the utilization of each resource in contention while minimizing the impact on each individual "leaving" compared to that "leaving" having exclusive access to all resources. You add more "leavings" to the mix until either (a) the management overhead of the "leavings management" outweighs the advantage gained by adding the "leaving" or some resource under contention is 100% utilized. This is how all multileaved processing works. However, I should not expect a linear increase in performance but some marginal increase.įor some definition of marginal, that is correct. You can create a filesystem that is resident in memory (that is called a RAMDISK or you can use the /dev/shm on Linux or whatever it is called on the Operating System you are using) and put a database there. I suppose that one could write a VFS that allowed a database to be stored in memory but currently that is not really the case.
Things that are "in memory" are not databases, they are temp stores. SQLite3 does not really support the concept of an "in memory database". Basically you are saying that parallel reads against an SQLite (in-memory) database are basically impossible.