Ponos – A simple yet powerful load generator in Erlang(github.com)
github.com
Ponos – A simple yet powerful load generator in Erlang
https://github.com/klarna/ponos
6 comments
I'd love to use this to test my application, but after reading through the docs, I'm not quite sure how to get the setup I'd like:
My application is a server which clients login and then issue commands to. As I'm imagining it, a user load generator would be creating and logging in users. But this is where I get fuzzy... should the user task also create a load generator which issues commands against the application as that user? Seems pretty simple, hopefully it's possible !
Excited to try this out.
My application is a server which clients login and then issue commands to. As I'm imagining it, a user load generator would be creating and logging in users. But this is where I get fuzzy... should the user task also create a load generator which issues commands against the application as that user? Seems pretty simple, hopefully it's possible !
Excited to try this out.
Where ponos is at currently its main purpose in the world is specialise in generating simple or complex load patterns.
A load_generator in essence is just a process generating triggers at requested frequency. Every trigger happens asynchronously so there is no way to thread state between triggers.
If there is enough interest I'd be happy to extend it to handle synchronous load generators where threading state makes sense. With that use case though, it'd be impossible to guarantee that the actual load matches the load_spec in all circumstances.
If you wish to keep state between triggers you have to implement this outside of ponos at this stage.
A load_generator in essence is just a process generating triggers at requested frequency. Every trigger happens asynchronously so there is no way to thread state between triggers.
If there is enough interest I'd be happy to extend it to handle synchronous load generators where threading state makes sense. With that use case though, it'd be impossible to guarantee that the actual load matches the load_spec in all circumstances.
If you wish to keep state between triggers you have to implement this outside of ponos at this stage.
I am also interested in load testing stateful sessions e.g. log in, wait, do stuff, wait, log out.
Using ponos this could be done by spawning a (gen_server-) process in the task which runs the session and then terminates.
In this scenario the load function would model the arrival rate of the users.
Sure thing. I guess you could even spawn a task that generates new load_generators. In that scenario I guess it could be useful to have the possibility to configure a load generator that terminates after the call_counter reaches a threshold.
Replying to my own post here, this is an example: https://gist.github.com/odo/6c59f604fda6390d034a
Thanks for the explanation!
Not the most flexible solution, but if you want the load spec to be authoritative you could allow it to recursively specify a different load generator rather than a task_runner. Instead of running a task, it would start a new load generator.
... hope I got some of the terminology right.
Not the most flexible solution, but if you want the load spec to be authoritative you could allow it to recursively specify a different load generator rather than a task_runner. Instead of running a task, it would start a new load generator.
... hope I got some of the terminology right.
I've put together a really trivial example here (in semi-pseudo code): https://gist.github.com/jool/1e83b22fec9d948194a4.
In the example I've modeled each of your uses as a load generator. So you would have to add one load generator per user. Let me know if you have any questions.
In the example I've modeled each of your uses as a load generator. So you would have to add one load generator per user. Let me know if you have any questions.
Thank you for this! I'll be trying it out in about a month, and I'll let you know hos it goes.
So. What you could do is implement your own task_runner.
For instance, if you wish to represent each user as a load generator, your task_runner's state could store each load generator's user information in the state indexed by name.
You would then log in the user during the init state.
I'm on the subway but I'll describe it more in detail when I get home.
For instance, if you wish to represent each user as a load generator, your task_runner's state could store each load generator's user information in the state indexed by name.
You would then log in the user during the init state.
I'm on the subway but I'll describe it more in detail when I get home.
I think it's probably from Greek mythology. Ponos was the God of hard labour - https://en.wikipedia.org/wiki/Ponos
Actually, it is. It's in the readme on the first line! :)
Ponos in modern Greek means "pain".
Just a comment on name - in Serbian "ponos" means "pride". So I guess author should be proud of his work :)
And in Russian "ponos" means "diarrhea" :(
Something the author (me) is aware of. See the Notes section of the README (https://github.com/klarna/ponos#ref1).
The original name is based on the Greek god of hard labor and toil (http://en.wikipedia.org/wiki/Ponos).
The original name is based on the Greek god of hard labor and toil (http://en.wikipedia.org/wiki/Ponos).
Ponos in grid besides being the god of Hard Labour also means pain itself in modern greek
Put your.. that! Y.. your load generator! To my.. my... HERE! My application! And j.. j.. JAM IT IN!
I think it is a good name.
To add though, this is a cool idea. I like it generates an internal-kind of load. Not necessarily driven from external requests. So this combined with tsung to test how the system behaves in various scenarios.
Operating under load is not something many people test. Search Erlang Factor talks and you'll find many talks by Erlang experts on load monitoring, load shedding and so on basically characterizing behaviour during overload conditions.