Should Database Front-End Applications be Parallel?

The answer is of course “it depends.” To examine the tradeoffs, let's review the diagram:

The main factor to consider is whether a single hardware thread can keep up with a user. If so, it is probably best to leave the applications as-is, continuing to let the database bear the brunt of the burden of shared-memory parallelism.

On the other hand, if the application is visibly degrading the response time, it might be wise to parallelize it. Here are a few reasons why parallelization might be needed:

1. Heavy computation, for example, synthesizeing full-rate video or doing data reduction on sensor inputs.
2. Multiple I/O requests, as might be the case for Web 2.0 applications. (Of course, asynchronous I/O might be another reasonable choice in this case.)
3. Power constraints might favor running multiple hardware threads at low clock frequency over running a smaller number of hardware threads at higher clock frequency — although this argument seems better aimed at the database rather than at the application.

The 1995 description of application leads me to believe that it should remain single-threaded, even here in 2009. Of course, the application might have changed over the past 14 years, so that the 2009 version might benefit from parallelization, or perhaps parallelization might enable attractive new features to be more easily added. As noted above, “it depends.”

This is not the last time I will tell you to use the right tool for the job!!!