Re: Grinder Feature Enhancements for Worker Notifications and Console Reporting

Hi Phil,

Thanks for the feedback.  I am starting to prototype the synchronisation API
to create the sync handles, wait for all handles across all agents to close
or reach the waiting point, and close the handles.  For this type of
blocking communication from the agent to the console it looks like I will
need to create a new blocking sender instance for the workers to use for
these sync handle operations, since they need a response from the console to
continue.  Would having a blocking sender instantiated at a high level in
the worker's code base (such as in the GrinderProcess class) be beneficial
for future coding projects, or do you think it would be best to retain the
blocking sender privately in my new synchronization classes?


David Smith
Information Sciences Institute
[email protected]
+1 (310)-448-9113


-----Original Message-----
From: Philip Aston [mailto:[email protected]] 
Sent: Saturday, May 29, 2010 8:39 AM
To: grinder-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [Grinder-development] Grinder Feature Enhancements for Worker
Notifications and Console Reporting

Hi David,

On 28/05/10 02:34, David Smith wrote:
>
> Good evening,
>
> Our organization is interested in using The Grinder for some 
> performance test measurements we will record.  There are a few 
> enhancements we would like to discuss and are willing to contribute 
> the code back to the community if there is interest in any of them.
>
> 1. *Ability to wait for a test to finish on all agent workers prior to 
> starting the next test.*  This would allow us to batch run a large 
> number of concurrent tests and help ensure that the same test is 
> actually running on all agents at any given time.  It seems like the 
> easiest way for us to do this is to run the console in headless mode 
> and enhance the Console API so that it allows listeners to be notified 
> when agents have started and finished processing a test.  We could 
> utilize this enhancement, along with the startWorkerProcesses() 
> method, to control when the next test starts on all agents.  I saw 
> that having a listener in the Console API was on the to-do list.
>

Yes, I've thought about doing something like this. I wouldn't base it on 
Test()'s though, but instead create a separate synchronisation API which 
the scripts would use. I don't think it would involve the console API, 
but would use the console for coordination.

I'd imagine an API that looks something like this:

     sync = grinder.synchronisation.register("my sync point") # create a 
sync handle

     ##

     sync.waitForAll()    # Blocks until all handles for "my sync point" 
have reached this point or have been closed

     ##

     sync.close()    # In case a script no longer wants to participate 
in a sync point. Will also happen automatically if the worker 
disconnects from the console.



> 2. *An option to publish detailed test results to the console.*  In 
> many cases the individual test results would contain too much data to 
> maintain in the console, making the summarized results the better 
> information to present.  However in our testing it would be more 
> useful to have all of the data collected from all the agents into a 
> single location by the console.
>

There may be a data volume issue here. Not sure.

> 3. *Collect statistics in a headless console.*  If our solution needs 
> to involve running the console in headless mode and sending all the 
> data collected to it, we will need to enhance the Console so that it 
> is able to record the data somehow.  I also saw that this is a To-do 
> list item.
>
> 4. *Push files from the console to the agents when running in headless 
> mode.*  We foresee ourselves having many agents deployed, so manually 
> transferring script changes to all of these files will be problematic 
> for us.
>

Yes, definitely both "to do"s

> Let me know if any of these enhancements are already underway by 
> someone else.  We would like our efforts to benefit the project as a 
> whole as well as our own needs, so feel free to discuss any additional 
> requirements or ideas regarding these enhancements with us and the list.
>

I won't be working on any of these in the near future, and I'd welcome 
such contributions. Please go ahead and prototype

Be aware that I'm a benevolent dictator and can be fussy about accepting 
patches, and will want to review things carefully before merging them 
back into the source tree, there's some hints at 
http://grinder.sourceforge.net/development/contributing.html. Start with 
some small things, and we'll proceed from there.

- Phil


----------------------------------------------------------------------------
--

_______________________________________________
Grinder-development mailing list
Grinder-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/grinder-development


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo