Re: TLP tools for stress testing and building test clusters in AWS
Hi Stefan, I have been working with Jon on developing the tool set. I can do a Zoom call tomorrow (Wednesday) at 11am AEST if that works for you? We can go through all the same information that Jon is going to go through in his call. Note that I am in the same timezone as you, so if tomorrow morning is no good we can always do the afternoon. Cheers, Anthony On Sat, 13 Apr 2019 at 22:38, Stefan Miklosovic < stefan.mikloso...@instaclustr.com> wrote: > Hi Jon, > > I would like be on that call too but I am off on Thursday. > > I am from Australia so 5pm London time is ours 2am next day so your > Wednesday morning is my Thursday night. Wednesday early morning so > your Tuesday morning and London's afternoon would be the best. > > Recording the thing would be definitely helpful too. > > On Sat, 13 Apr 2019 at 07:45, Jon Haddad wrote: > > > > I'd be more than happy to hop on a call next week to give you both > > (and anyone else interested) a tour of our dev tools. Maybe something > > early morning on my end, which should be your evening, could work? > > > > I can set up a Zoom conference to get everyone acquainted. We can > > record and post it for any who can't make it. > > > > I'm thinking Tuesday, Wednesday, or Thursday morning, 9AM Pacific (5pm > > London)? If anyone's interested please reply with what dates work. > > I'll be sure to post the details back here with the zoom link in case > > anyone wants to join that didn't get a chance to reply, as well as a > > link to the recorded call. > > > > Jon > > > > On Fri, Apr 12, 2019 at 10:41 AM Benedict Elliott Smith > > wrote: > > > > > > +1 > > > > > > I’m also just as excited to see some standardised workloads and test > bed. At the moment we’re benefiting from some large contributors doing > their own proprietary performance testing, which is super valuable and > something we’ve lacked before. But I’m also keen to see some more > representative workloads that are reproducible by anybody in the community > take shape. > > > > > > > > > > On 12 Apr 2019, at 18:09, Aleksey Yeshchenko > wrote: > > > > > > > > Hey Jon, > > > > > > > > This sounds exciting and pretty useful, thanks. > > > > > > > > Looking forward to using tlp-stress for validating 15066 performance. > > > > > > > > We should touch base some time next week to pick a comprehensive set > of workloads and versions, perhaps? > > > > > > > > > > > >> On 12 Apr 2019, at 16:34, Jon Haddad wrote: > > > >> > > > >> I don't want to derail the discussion about Stabilizing Internode > > > >> Messaging, so I'm starting this as a separate thread. There was a > > > >> comment that Josh made [1] about doing performance testing with real > > > >> clusters as well as a lot of microbenchmarks, and I'm 100% in > support > > > >> of this. We've been working on some tooling at TLP for the last > > > >> several months to make this a lot easier. One of the goals has been > > > >> to help improve the 4.0 testing process. > > > >> > > > >> The first tool we have is tlp-stress [2]. It's designed with a "get > > > >> started in 5 minutes" mindset. My goal was to ship a stress tool > that > > > >> ships with real workloads out of the box that can be easily tweaked, > > > >> similar to how fio allows you to design a disk workload and tweak it > > > >> with paramaters. Included are stress workloads that stress LWTs > (two > > > >> different types), materialized views, counters, time series, and > > > >> key-value workloads. Each workload can be modified easily to change > > > >> compaction strategies, concurrent operations, number of partitions. > > > >> We can run workloads for a set number of iterations or a custom > > > >> duration. We've used this *extensively* at TLP to help our > customers > > > >> and most of our blog posts that discuss performance use it as well. > > > >> It exports data to both a CSV format and auto sets up prometheus for > > > >> metrics collection / aggregation. As an example, we were able to > > > >> determine that the compression length set on the paxos tables > imposes > > > >> a significant overhead when using the Locking LWT workload, which > > > >> simulates locking and unlocking of rows. See CASSANDRA-15080 for > > > >> details. > > > >> > > > >> We have documentation [3] on the TLP website. > > > >> > > > >> The second tool we've been working on is tlp-cluster [4]. This tool > > > >> is designed to help provision AWS instances for the purposes of > > > >> testing. To be clear, I don't expect, or want, this tool to be used > > > >> for production environments. It's designed to assist with the > > > >> Cassandra build process by generating deb packages or re-using the > > > >> ones that have already been uploaded. Here's a short list of the > > > >> things you'll care about: > > > >> > > > >> 1. Create instances in AWS for Cassandra using any instance size and > > > >> number of nodes. Also create tlp-stress instances and a box for > > > >> monitoring > > > >> 2.
Re: TLP tools for stress testing and building test clusters in AWS
Hey all, I've set up a Zoom call for 9AM Pacific time. Everyone's welcome to join. https://zoom.us/j/189920888 Looking forward to a good discussion on how we can all pitch in on getting 4.0 out the door. Jon On Sat, Apr 13, 2019 at 9:14 AM Jonathan Koppenhofer wrote: > > Wednesday would work for me. > > We use and (slightly) contribute to tlp tools. We are platform testing and > beginning 4.0 testing ourselves, so an in person overview would be great! > > On Sat, Apr 13, 2019, 8:48 AM Aleksey Yeshchenko > wrote: > > > Wednesday and Thursday, either, at 9 AM pacific WFM. > > > > > On 13 Apr 2019, at 13:31, Stefan Miklosovic < > > stefan.mikloso...@instaclustr.com> wrote: > > > > > > Hi Jon, > > > > > > I would like be on that call too but I am off on Thursday. > > > > > > I am from Australia so 5pm London time is ours 2am next day so your > > > Wednesday morning is my Thursday night. Wednesday early morning so > > > your Tuesday morning and London's afternoon would be the best. > > > > > > Recording the thing would be definitely helpful too. > > > > > > On Sat, 13 Apr 2019 at 07:45, Jon Haddad wrote: > > >> > > >> I'd be more than happy to hop on a call next week to give you both > > >> (and anyone else interested) a tour of our dev tools. Maybe something > > >> early morning on my end, which should be your evening, could work? > > >> > > >> I can set up a Zoom conference to get everyone acquainted. We can > > >> record and post it for any who can't make it. > > >> > > >> I'm thinking Tuesday, Wednesday, or Thursday morning, 9AM Pacific (5pm > > >> London)? If anyone's interested please reply with what dates work. > > >> I'll be sure to post the details back here with the zoom link in case > > >> anyone wants to join that didn't get a chance to reply, as well as a > > >> link to the recorded call. > > >> > > >> Jon > > >> > > >> On Fri, Apr 12, 2019 at 10:41 AM Benedict Elliott Smith > > >> wrote: > > >>> > > >>> +1 > > >>> > > >>> I’m also just as excited to see some standardised workloads and test > > bed. At the moment we’re benefiting from some large contributors doing > > their own proprietary performance testing, which is super valuable and > > something we’ve lacked before. But I’m also keen to see some more > > representative workloads that are reproducible by anybody in the community > > take shape. > > >>> > > >>> > > On 12 Apr 2019, at 18:09, Aleksey Yeshchenko > > wrote: > > > > Hey Jon, > > > > This sounds exciting and pretty useful, thanks. > > > > Looking forward to using tlp-stress for validating 15066 performance. > > > > We should touch base some time next week to pick a comprehensive set > > of workloads and versions, perhaps? > > > > > > > On 12 Apr 2019, at 16:34, Jon Haddad wrote: > > > > > > I don't want to derail the discussion about Stabilizing Internode > > > Messaging, so I'm starting this as a separate thread. There was a > > > comment that Josh made [1] about doing performance testing with real > > > clusters as well as a lot of microbenchmarks, and I'm 100% in support > > > of this. We've been working on some tooling at TLP for the last > > > several months to make this a lot easier. One of the goals has been > > > to help improve the 4.0 testing process. > > > > > > The first tool we have is tlp-stress [2]. It's designed with a "get > > > started in 5 minutes" mindset. My goal was to ship a stress tool > > that > > > ships with real workloads out of the box that can be easily tweaked, > > > similar to how fio allows you to design a disk workload and tweak it > > > with paramaters. Included are stress workloads that stress LWTs (two > > > different types), materialized views, counters, time series, and > > > key-value workloads. Each workload can be modified easily to change > > > compaction strategies, concurrent operations, number of partitions. > > > We can run workloads for a set number of iterations or a custom > > > duration. We've used this *extensively* at TLP to help our customers > > > and most of our blog posts that discuss performance use it as well. > > > It exports data to both a CSV format and auto sets up prometheus for > > > metrics collection / aggregation. As an example, we were able to > > > determine that the compression length set on the paxos tables imposes > > > a significant overhead when using the Locking LWT workload, which > > > simulates locking and unlocking of rows. See CASSANDRA-15080 for > > > details. > > > > > > We have documentation [3] on the TLP website. > > > > > > The second tool we've been working on is tlp-cluster [4]. This tool > > > is designed to help provision AWS instances for the purposes of > > > testing. To be clear, I don't expect, or want, this tool to be used > > > for production environments. It's designed
Re: Jira: Author Field
Ok, there’s now an ‘Authors' field > On 8 Apr 2019, at 15:03, Joshua McKenzie wrote: > >> >> It also permits searching in Jira for tickets by a particular person > > That makes sense from an attribution perspective. Certainly easier than > git grepping (low bar on usability, that). > > Having a multi-user Authors field, in addition to the multi-user Reviewers >> field that we already have, allows to more accurately reflect on the ticket >> who contributed in what capacity. > > Also gives us symmetry / consistency, which scratches my OCD itch. > > +1 from me. > > On Mon, Apr 8, 2019 at 9:18 AM Aleksey Yeshchenko > wrote: > >> Some of it is just for clear attribution. >> >> Occasionally, you do get an extensive review that borders on >> authoring/coauthoring. >> >> Sometimes you get a large body of work co-created by several people in >> author capacity. >> >> Having a multi-user Authors field, in addition to the multi-user Reviewers >> field that we already have, allows to more accurately reflect on the ticket >> who contributed in what capacity. >> >>> On 8 Apr 2019, at 14:01, Joshua McKenzie wrote: >>> >>> What problem are we trying to solve w/this proposed change? >>> >>> Is the thinking for live querying of things in progress, or is the >> thinking >>> for after-the-fact research to determine who wrote a thing to reach out >> to >>> them for context? If the latter, does a change in JIRA metadata give us >>> more context than good git commit message hygiene (i.e. list all authors >> on >>> commit msg)? >>> >>> fwiw, no religion on the topic here. Just curious. >>> >>> >>> On Mon, Apr 8, 2019 at 8:55 AM Benedict Elliott Smith < >> bened...@apache.org> >>> wrote: >>> A couple of people have recently raised the possibility of an Author >> field in JIRA, that permits multiple authors (much like we now support >> multiple reviewers). Unfortunately this can never be quite as clean as Reviewers, as Assignee is a core Jira field and cannot be replaced entirely by Authors. >> However, when we (hopefully later) get the ScriptRunner add-on, we might be able >> to manage it transparently. In the meantime, I don’t see any harm in introducing an Author field anyway. Does anyone have any objections? - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
