Performance Considerations: PARALLEL

The form of the first example takes a single row as its input. When a single URL is specified, SOAPCALL sends the request to that one URL and waits for a response. If multiple URLs are specified, SOAPCALL sends a request to the first URL in the list, waits for a response, sends a request to the second URL, and on down the list. The PARALLEL option controls concurrency, so if PARALLEL(n) is specified, requests are sent concurrently from each Thor node, with up to n requests in flight at once from each node.

The form of the second example takes a dataset as its input. When a single URL specified, the default behaviour is to send two requests with the first and second rows concurrently, wait for a response, send the third rows, and so on down the dataset, with up to two requests in flight at once. If PARALLEL(n) is specified, it sends n requests with the first n rows concurrently from each Thor node, and so on, with up to n requests in flight at once from each node.

In an ideal world you would specify a PARALLEL value that multiplies out to at least the number of Roxie URLs, so that every available host can work simultaneously. Also, if you're using a dataset as input, you might want to try a value several times the number of URLs. However, this could cause network contention (timeouts and dropped connections) if set too high.

You should add the PARALLEL option to the code from both previous examples to see what effect differing values may have in your environment.