You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@bigtop.apache.org by "Evans Ye (JIRA)" <ji...@apache.org> on 2015/12/02 16:44:11 UTC

[jira] [Commented] (BIGTOP-2161) [bigpetstore] transaction-queue Implment/Brainstorm ideas for global data rate.

    [ https://issues.apache.org/jira/browse/BIGTOP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035989#comment-15035989 ] 

Evans Ye commented on BIGTOP-2161:
----------------------------------

Not really sure if this is the right way to go considering the effort to take...
I'm currently using something called Akka, which is an actor model implementation. It has an easy to setup cluster mechanism. You can send messages across actors running on top of different JVM processes. Interesting in it?

> [bigpetstore] transaction-queue Implment/Brainstorm ideas for global data rate.
> -------------------------------------------------------------------------------
>
>                 Key: BIGTOP-2161
>                 URL: https://issues.apache.org/jira/browse/BIGTOP-2161
>             Project: Bigtop
>          Issue Type: Improvement
>          Components: blueprints
>    Affects Versions: backlog
>            Reporter: jay vyas
>             Fix For: backlog
>
>
> - We right now are able to generate n transactions a second per daemon.  
> - However, I'd like to implement a global data rate, so that generators slow down/speed up at diffferent times. 
> Some ideas on how to do this. 
> - Embed a "rate" function into the transaction generator options... such that it randomly speeds up/slows down over time.   downside: there is no real global data rate here.  its just a bunch of coordinated data generators.  
> - Send a new parameter, a REST endpoint, which can be scraped to get a hint of global data rate.  The generators can use that endpoint to calibrate how fast/slow they should be going.
> [~rnowling] [~evans_ye] [~sekikn]  im leaning towards #2.  Any thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)