| Next Page | Prev Page | Main Index | Home |
Contributing to the performance of MPbase is a fundamental
change in the way the computer hardware is used. This change is
to a resource-centric paradigm. This leads to a whole new set
of performance constraints. These constraints are far less restrictive
than those from the current task-centric model. This allows far
greater performance than would otherwise be possible.
Almost without exception, current computer-based systems run in
a task-centric paradigm. Under this paradigm the task to be done
is the central focus. The system resources: disks, memory, I/O
connections, etc. are queued up and shared between the tasks.
Queuing theory describes, in agonizing detail, why this paradigm
can run only just so fast.
As long as systems remain task-centric, the theoretical upper
limit to performance will be described by queuing theory. This
artificial upper limit to performance is nowhere near the true
limits of the underlying hardware. Prior to MPbase and
this conceptual breakthrough, performance like this was only possible
through stand-alone or single-user systems. Although very fast,
such systems are not very practical.
Resource-centric systems behave in a very different manner. In
this paradigm the task is fragmented and placed in resource queues.
Each resource is owned by one system task (daemon). All the work
requiring use of any one resource is done by the one daemon owning
it. The results are fed back to a daemon owning the "task,"
this last daemon combines the products of the resource-owning
daemons to produce or validate the completed "task."
To some extent all systems do contain some of both paradigms.
However, there is a line beyond which the resource-centric model
"short circuits" queuing theory. This is where the full
power of the underlying hardware is available for end-user useful
work. This is the realm of one-to-one decoupled queues. Some would
claim that this environment is as odd and hard to use as stand-alone
mode. However, MPbase allows this operational model to
be applied to real world information problems.
A good example comes from several years ago. Mirroring was being
added to a system. The sample run took one hour before the change.
The change was first added in a task-centric manner. This took
the run time to two hours. That change was then removed and reapplied
in a resource-centric manner. This took the run time to one hour
and five minutes.
This example was not done just to validate the resource-centric model. It came about due to a combination of disbelief and developer brain fade. A little bit of task-centric behavior cannot be all that bad? WRONG! Once the new rules are understood, this is not a hard paradigm to follow. When you make a mistake it tends to be easy to find and almost always falls in the "that was dumb" category. Not counting the test runs, all of the changes above took less than one hour to complete.
| Next Page | Prev Page | Main Index | Home | © 1998-2004 NPSI |