Parallel Processing


Parallel processing is used on all modern computers without the knowledge of the user today. Even modern smartphones have time-shared multitasking and in fact symmetric multi-processing (SMP support) with their multi-core processors. Yet the average application software designer and developer still lives in a strictly sequential world. We use parallel processing in business applications we design extensively, to get faster response times and manage workloads better.


Having grown up in the world of Unix systems, we look upon daemons with a friendly eye. We have often used long-running background processes (i.e. daemons) to take up part of the workload when the front-end systems would have become overloaded. For instance, if a user interface is expected to generate a complex ad hocreport from a database, a complex synchronous SQL query will make the user impatient. In such situations, we create a background process which runs the queries and stores the results in a text file or HTML page. The UI code merely queues a request message for this background process, asking for the report the user needs. After this, the UI displays a message to the user informing him that his report has been queued for generation. The user may return to the same page at any future time to view the report if it has already been generated. Since the report-generating daemon fires only one complex SQL query at a time, the load on the database is kept within limits, improving overall system response for interactive transactions and other rapid queries.

A background daemon is also extremely useful is for maintaining a shared repository of information. For instance, if there is a need to maintain a persistent set of key-value pairs, then querying and updating a SQL table each time may be much slower than using UDP packets to communicate with a background process which holds this data in memory. In some sense, this is what the memcached daemon provides. Such daemons become even more attractive if the information structure is variable and an update may contain one or a dozen attributes in one packet. This sort of information may also be maintained in a shared Berkeley DB file, but mutex locks on the file may tend to slow things down — a dedicated daemon does not need to lock its own data store