The design of the multi-processing needs to ensure re-entrant code and idempotency for repeated calls to the /run_tests web service endpoint, using parallel processing runs (using Multiprocessor Pools?).
For example, we may need to redesign this to better handle multiple users testing concurrently. Alternately, we can buffer the test requests with a FIFO queue (test runs executed sequentially, as received).
A possible interesting user scenario driving this use case is for end users to want to rerun a subset of tests, on a subset of edges for a subset of KPs. That might make multi-user running of tests a bit more of a reality (hence, need concurrently running processes).
The stack has that potential... we just aren't assuming it yet.
The design of the multi-processing needs to ensure re-entrant code and idempotency for repeated calls to the /run_tests web service endpoint, using parallel processing runs (using Multiprocessor Pools?).
For example, we may need to redesign this to better handle multiple users testing concurrently. Alternately, we can buffer the test requests with a FIFO queue (test runs executed sequentially, as received).
A possible interesting user scenario driving this use case is for end users to want to rerun a subset of tests, on a subset of edges for a subset of KPs. That might make multi-user running of tests a bit more of a reality (hence, need concurrently running processes).
The stack has that potential... we just aren't assuming it yet.