0

I am building a small utility that packages Locust - performance testing tool (https://locust.io/) and deploys it on azure functions. Just a fun side project to get some hands on with the serverless craze.

Here's the git repo: https://github.com/amanvirmundra/locust-serverless.

Now I am thinking that it would be great to run locust test in distributed mode on serverless architecture (azure functions consumption plan). Locust supports distributed mode but it needs the slaves to communicate with master using it's IP. That's the problem!!

I can provision multiple functions but I am not quite sure how I can make them talk to each other on the fly(without manual intervention).

Thinking out loud:

  1. Somehow get the IP of the master function and pass it on to the slave functions. Not sure if that's possible in Azure functions, but some people have figured a way to get an IP of azure function using .net libraries. Mine is a python version but I am sure if it can be done using .net then there would be a python way as well.
  2. Create some sort of a VPN and map a function to a private IP. Not sure if this sort of mapping is possible in azure.
  3. Some has done this using AWS Lambdas (https://github.com/FutureSharks/invokust). Ask that person or try to understand the code.

Need advice in figuring out what's possible at the same time keeping things serverless. Open to ideas and/or code contributions :)

Update

This is the current setup:

  1. The performance test session is triggered by an http request, which takes in number of requests to make, the base url, and no. of concurrent users to simulate.
  2. Locustfile define the test setup and orchestration.
  3. Run.py triggers the tests.

What I want to do now, is to have master/slave setup (cluster) for a massive scale perf test.

  • I would imagine that the master function is triggered by an http request, with a similar payload.
  • The master will in turn trigger slaves.
  • When the slaves join the cluster, the performance session would start.
Amanvir Mundra
  • 420
  • 1
  • 6
  • 20

1 Answers1

1

What you describe doesn't sounds like a good use-case for Azure Functions.

Functions are supposed to be:

  • Triggered by an event
  • Short running (max 10 minutes)
  • Stateless and ephemeral

But indeed, Functions are good to do load testing, but the setup should be different:

  • You define a trigger for your Function (e.g. HTTP, or Event Hub)
  • Each function execution makes a given amount of requests, in parallel or sequentially, and then quits
  • There is an orchestrator somewhere (e.g. just a console app), who sends "commands" (HTTP call or Event) to trigger the Function

So, Functions are "multiplying" the load as per schedule defined by the orchestrator. You rely on Consumption Plan scalability to make sure that enough executions are provisioned at any given time.

The biggest difference is that function executions don't talk to each other, so they don't need IPs.

I think the mentioned example based on AWS Lambda is just calling Lambdas too, it does not setup master-client lambdas talking to each other.

I guess my point is that you might not need that Locust framework at all, and instead leverage the built-in capabilities of autoscaled FaaS.

Mikhail Shilkov
  • 34,128
  • 3
  • 68
  • 107
  • If you check my repo the readme describes just that. The load testing session is triggered by an http request. The given amount of requests is defined in the payload, the orchestrator is basically the python scripts (locustfile). I am ok with the 10 mins session, however in theory it could be extended to unlimited if you convert the app consumption plan to monthly/fixed - that would however not make it truly serverless. – Amanvir Mundra May 15 '18 at 11:39
  • I would imagine in a master - slave setup, the master would be triggered by an http request. The master in turn will trigger slave functions. Once they join the cluster, the load testing session will start. At the end of the session, the master would return a response with the stats of the perf test session. I believe these are stateless since every trigger is independent of the other. – Amanvir Mundra May 15 '18 at 11:42
  • Updated the question, just to elaborate on the current setup. – Amanvir Mundra May 15 '18 at 11:51
  • @AmanvirMundra So the only thing missing is replace custom IP-based protocol with HTTP calls. Doesn't the library allow that? – Mikhail Shilkov May 15 '18 at 12:12
  • I don’t think it does. Atleast the documentation doesn’t say that. I’ll ask the owners of the library and see if they have any suggestions / workarounds. – Amanvir Mundra May 15 '18 at 12:16
  • @AmanvirMundra I can imagine it doesn't, because it's a different model. One thing is to provision N slaves and then manage them, and the other is to send HTTP commands to a pool of short-lived workers. – Mikhail Shilkov May 15 '18 at 12:18
  • I agree on the auto scale FaaS. Although, it would be fun to see if functions can work in a cluster, with one being a master. – Amanvir Mundra May 15 '18 at 12:23