You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@usergrid.apache.org by Alex Karasulu <ak...@apache.org> on 2014/04/10 23:48:06 UTC
[ug-chop] Progress on a distributed stress testing tool for Usergrid
Hello Devs,
<OT>
I hope everyone is well and had a great time at Apache Con 2014 this week.
</OT>
I've been diverted from working on UG proper in an effort to be able to
thoroughly and easily stress test it in a production-like environment. This
includes testing methods, classes, and components in isolation as well the
entire system. I've been working on the code here: [0] with more info at
[1] and [2]. Initially I was hoping to use an existing toolkit to do this
(since frankly I did not wanted to deal with writing testing code) however
nothing really satisfied all our requirements:
o test methods, classes and components in isolation as well as the entire
system,
o be a able to leverage existing unit tests as stress tests with just an
annotation,
o seamlessly integrate with our build and CI system
o historically track the performance with metrics over the life of the
project
o auto-[de]provision clusters needed (C* and ES) for the annotated tests
to hit
Initially, I tried achieving this with JMeter and other such stress test
tools but it just didn't fly. So I thought I could whip up a small library
to get started and return back to the core persistence code. I did not
realize the time it would take. Honestly, I thought it would be throw away
code eventually and did not want to clutter our repository, while
generating needless traffic. Plus I needed some help and asked friends at
Safehaus who also had a similar need for their assistance and thankfully
they also helped out.
So we've progressed considerably however IMHO I think this code belongs at
Apache alongside the UG code base which it was originally designed to
stress test. So now I have some questions:
(1) Should we import this into our source code repository?
(2) If yes to (1) then, where should it go? In a 'chop' folder as a peer of
the portal, sdk, and stack folders?
(3) Do we need to get an ICLA on file for the guys who helped out while it
was hosted for the brief convenient time it was kept at the Safehaus?
-----
[0] - http://stash.safehaus.org/projects/CHOP/repos/main/browse
[1] - http://jira.safehaus.org/browse/CHOP
[2] - http://confluence.safehaus.org/display/CHOP/Home
--
Best Regards,
-- Alex
Re: [ug-chop] Progress on a distributed stress testing tool for
Usergrid
Posted by Rod Simpson <ro...@rodsimpson.com>.
+1 This sounds awesome! Definitely a great addition to Usergrid.
Rod
--
Rod Simpson
@rockerston
rodsimpson.com
On April 10, 2014 at 8:44:35 PM, Todd Nine (todd.nine@gmail.com) wrote:
IMHO I think
1) Yes we should.
2) If we're taking the approach that we release SDKs separately from
the stack, then I think this can just be another tool that we release
independently as well. This makes all the source available in one
location, and easier for our users to grok and contribute.
On Thu, Apr 10, 2014 at 9:48 PM, Alex Karasulu <ak...@apache.org> wrote:
> Hello Devs,
>
> <OT>
>
> I hope everyone is well and had a great time at Apache Con 2014 this week.
>
> </OT>
>
> I've been diverted from working on UG proper in an effort to be able to
> thoroughly and easily stress test it in a production-like environment. This
> includes testing methods, classes, and components in isolation as well the
> entire system. I've been working on the code here: [0] with more info at
> [1] and [2]. Initially I was hoping to use an existing toolkit to do this
> (since frankly I did not wanted to deal with writing testing code) however
> nothing really satisfied all our requirements:
>
> o test methods, classes and components in isolation as well as the entire
> system,
>
> o be a able to leverage existing unit tests as stress tests with just an
> annotation,
>
> o seamlessly integrate with our build and CI system
>
> o historically track the performance with metrics over the life of the
> project
>
> o auto-[de]provision clusters needed (C* and ES) for the annotated tests
> to hit
>
> Initially, I tried achieving this with JMeter and other such stress test
> tools but it just didn't fly. So I thought I could whip up a small library
> to get started and return back to the core persistence code. I did not
> realize the time it would take. Honestly, I thought it would be throw away
> code eventually and did not want to clutter our repository, while
> generating needless traffic. Plus I needed some help and asked friends at
> Safehaus who also had a similar need for their assistance and thankfully
> they also helped out.
>
> So we've progressed considerably however IMHO I think this code belongs at
> Apache alongside the UG code base which it was originally designed to
> stress test. So now I have some questions:
>
> (1) Should we import this into our source code repository?
>
> (2) If yes to (1) then, where should it go? In a 'chop' folder as a peer of
> the portal, sdk, and stack folders?
>
> (3) Do we need to get an ICLA on file for the guys who helped out while it
> was hosted for the brief convenient time it was kept at the Safehaus?
>
> -----
>
> [0] - http://stash.safehaus.org/projects/CHOP/repos/main/browse
>
> [1] - http://jira.safehaus.org/browse/CHOP
>
> [2] - http://confluence.safehaus.org/display/CHOP/Home
>
>
> --
> Best Regards,
> -- Alex
Re: [ug-chop] Progress on a distributed stress testing tool for Usergrid
Posted by Todd Nine <to...@gmail.com>.
IMHO I think
1) Yes we should.
2) If we're taking the approach that we release SDKs separately from
the stack, then I think this can just be another tool that we release
independently as well. This makes all the source available in one
location, and easier for our users to grok and contribute.
On Thu, Apr 10, 2014 at 9:48 PM, Alex Karasulu <ak...@apache.org> wrote:
> Hello Devs,
>
> <OT>
>
> I hope everyone is well and had a great time at Apache Con 2014 this week.
>
> </OT>
>
> I've been diverted from working on UG proper in an effort to be able to
> thoroughly and easily stress test it in a production-like environment. This
> includes testing methods, classes, and components in isolation as well the
> entire system. I've been working on the code here: [0] with more info at
> [1] and [2]. Initially I was hoping to use an existing toolkit to do this
> (since frankly I did not wanted to deal with writing testing code) however
> nothing really satisfied all our requirements:
>
> o test methods, classes and components in isolation as well as the entire
> system,
>
> o be a able to leverage existing unit tests as stress tests with just an
> annotation,
>
> o seamlessly integrate with our build and CI system
>
> o historically track the performance with metrics over the life of the
> project
>
> o auto-[de]provision clusters needed (C* and ES) for the annotated tests
> to hit
>
> Initially, I tried achieving this with JMeter and other such stress test
> tools but it just didn't fly. So I thought I could whip up a small library
> to get started and return back to the core persistence code. I did not
> realize the time it would take. Honestly, I thought it would be throw away
> code eventually and did not want to clutter our repository, while
> generating needless traffic. Plus I needed some help and asked friends at
> Safehaus who also had a similar need for their assistance and thankfully
> they also helped out.
>
> So we've progressed considerably however IMHO I think this code belongs at
> Apache alongside the UG code base which it was originally designed to
> stress test. So now I have some questions:
>
> (1) Should we import this into our source code repository?
>
> (2) If yes to (1) then, where should it go? In a 'chop' folder as a peer of
> the portal, sdk, and stack folders?
>
> (3) Do we need to get an ICLA on file for the guys who helped out while it
> was hosted for the brief convenient time it was kept at the Safehaus?
>
> -----
>
> [0] - http://stash.safehaus.org/projects/CHOP/repos/main/browse
>
> [1] - http://jira.safehaus.org/browse/CHOP
>
> [2] - http://confluence.safehaus.org/display/CHOP/Home
>
>
> --
> Best Regards,
> -- Alex