jool

6 ms·

1. 1.▲
   by jool 12y ago

   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
2. 2.▲
   by jool 12y ago

   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 t
3. 3.▲
   by jool 12y ago

   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 nam
4. 4.▲
   by jool 12y ago

   For your particular use case though I'd just login and pass the user information as part of the task. The load_generator would then not be concerned about logging in but only issuing commands.
5. 5.▲
   by jool 12y ago

   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 asynchron
6. 6.▲
   by jool 12y ago

   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&