Factor out remote execution engine

[AndreLouisCaron]

(Redirecting from cicada-load/cicada#16.)

Hi all,

My employer has an internal legacy load testing tool that was developed before things like Locust started becoming available. We'd like to replace this with something more "standard" for a variety of reasons, including the increased chance that a new hire has prior experience with the tools we use.

Since we're a Python shop, I find Locust looks like a good candidate for a replacement.

However, all our new code is heavily based on asyncio and we'd like to use that as the main "scripting" of our load test scenarios.

Looking at locust, I can see that it has two main "parts":

1. A framework/DSL for scripting scenarios as state machines
2. A remote code execution engine

I'm really interested in the remote code execution engine as that is a direct replacement for our legacy tool. The state machine framework/DSL is of much lower interest to me because straight asyncio is actually more convenient for us.

The thing is that I can't figure out how to use the remote code execution engine to distribute my asyncio-based scenarios because it seems like the framework and engine are glued together intimately.

I'm wondering if it would make sense to split these two apart in a way that makes the execution engine a separate project which could be imported as a dependency of Locust. With the proper approach, I think this could be made transparent to Locust's users but make the engine more suitable for other scripting approaches.

Does this make any sense to you?