Query Net

Subnets can sometimes be too effective in cutting up a network. The item subnet is very common, where each item can be solved on its own in any order without impacting other items. But the process for a single item may be completed in less than one second. If there are hundreds of thousands of items, the app and database servers will spend more time managing tasks that completed the calculation.

A query net of say 100 items that wraps the subnet of 1 item can allow a task to run 100 subnets. This cuts the number of tasks – and the management of those tasks – by two orders of magnitude while the logic within the subnet is not impacted.

Sample Subnet

Subnet(item)

Read

Do some work on item

Write

Simple Converting to Query Net

For each item in query net

Subnet(item)

Read

Do some work on item

Write

Low risk of regression issues because the subnet is not impacted. There may be some issue in that the Read and Write are not embedded in the process. It’s limited in that they are focused on single item. But some extra thought may actually be able to improve.

Complex Converting to Query Net

For each item in query net

Read

Subnet(item)

Read

Do some work on item

Write

The complex solution requires more rewriting of the original subnet so carries more risk. If trying to fix an engine in production, this may not be the best choice. But if writing the read or write queries is straightforward, then this can actually improve performance. The write, for example, is only holding locks on the table for a brief moment while all the writes are executed, as opposed to waiting for all the processing to be completed.