Multicore support

[artilleryio]

Multicore support

[zommerfelds]

@hassy, by auto-scaling I meant that I wanted to test my system as a whole with a load balancer and an auto-scaling group. What that means is that as I put load on the service with Artillery, I want to see nodes being automatically added to the load balancer and being able to take more load. With multiple nodes I can easily support thousands of requests per second, which is hard to create load for with Artillery on a single core.

[Nepoxx]

Artillery should take advantage of every CPU available.

Just make sure it's configurable! I like using artillery on the same host as I dev on (e2e tests), so I need to leave some CPUs for the server itself :)

[steveschnepp]

This isn't very high on my list either, as even with only 1 core, you can already throw some serious traffic to servers.

And, I guess it would make artillery much more complex.

[zommerfelds]

Where is progress being tracked for https://artillery.io/blog/artillery-20-preview-multicore?
I've had cases where Artillery didn't generate enough load for my distributed tests with auto-scaling.

[hassy]

@zommerfelds curious by what you mean by "auto-scaling". Multicore support hasn't been a huge priority, but you can try the beta support by setting a couple of environment variables, and then running Artillery as normal:

• MULTICORE=true -- enable multicore support
• ARTILLERY_WORKERS=3 -- how many CPUs to use, total CPUs - 1 is usually a good value

[zommerfelds]

Your multicore settings seem to work fairly well.
Two small issues:
Warning: High CPU usage warning (pids: [object Object],[object Object],[object Object]).

1. PIDs not showing
2. Should we show a warning if I have a full core free?

[zommerfelds]

Actually not, there is a bigger issue for me: there seems to be some kind of memory leak. When I run
MULTICORE=true ARTILLERY_WORKERS=3 artillery quick -r 1000 -d 180 -o $out $target
I quickly use up 4GB of memory. At the end of the run (after printing Log file: ...) the process hangs and seems to be waiting for the workers. If press Ctrl-C, the node processes still hang around. When I start Artillery again once or twice I run out of 8GB with an allocation error.

Are we running blocking operations that don't let GC run?
BTW, this is probably because the endpoint I'm testing is queuing up request and causing huge latencies.

[hassy]

@zommerfelds thanks for the details! Yes it could be due to JSON parse/stringify calls exacerbated by the way the intermediate latency, throughput etc metrics are stored in memory while a test is running. There's a refactoring in progress to make the latter much more efficient which should land in the preview release in the next couple of weeks.

Depending on your needs, Artillery Pro may be worth taking a look at - you can scale out your tests horizontally to run from multiple containers / IPs (and if you go with the AWS Fargate option there's no infrastructure to set up or manage).

[aranair]

Hmmm, phases with rampTo + multicore set to true seem to distribute it well, but when it proceeds to the sustained phases e.g. outright arrivalRate: max_rate goes back to using a single core and the CPU catches fire :/

[hassy]

Artillery v2 is multithreaded by default, closing this