Splitting performance tickets into chunks

[Łukasz Lewczyński]

Hi all,

In the previous and current sprint we have a few tickets to introduce performance tests for existing endpoints. Currently we have one ticket (example: OLMIS-3211) for:

1. creating performance tests,
2. checking (if needed) why those endpoints does not fit requirements
3. improving endpoints to fit requirements

I think we could split this kind of tickets into three tickets instead of having one. One thing is to show that there is a progres in tickets. Currently tickets are in in progress or in review columns by several days because endpoints in most cases do not pass requirements. Also it always better to have few smaller tickets that are focused on single thing (like adding tests) in the sprint instead of one big ticket that have everything.

Another thing is that sometimes is very hard to find a good way to improve endpoints. For example the delete inventory item endpoint has only three steps:

1. find object in database
2. check permissions
3. delete object from database.

In the ticket this endpoint should be executed in 500ms but p90 is equal to 635ms (taken from the last performance execution on CI).

So sometimes investigation part will require starting a discussion on dev group about how we would like to improve some part of codes. I think permission strings are good example here.

If this approach does not sound as a great idea maybe we could have rule: one endpoint one performance test ticket.

What do you think about that?

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewc...@soldevelo.com

SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

[Chongsun Ahn]

Hey Łukasz,

This is a good point and normally we would not want to create tickets like this. We only created OLMIS-3211 because all of the CCE tickets up to that point had not had any performance acceptance criteria and no tests had been created, since CCE was started before our performance tooling was in place.

Now that we have a framework for performance testing, we should include performance acceptance criteria for all new tickets that introduce new backend APIs, instead of creating big performance tickets. If a ticket introduces multiple APIs, we can potentially separate it out into multiple tickets. We can evaluate if that’s necessary on a case-by-case basis.

Shalom,
Chongsun
​
-- ​
There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs...@villagereach.org

Software Development Engineer

 

VillageReach Starting at the Last Mile

2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536   CELL: 1.206.910.0973   FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook, Twitter and our Blog

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53xWXzmByAYv2Aq3KOGDxhm9cfKVZ6KMqT-0zsq9iHZ-ng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Nikodem Graczewski]

Hey everyone,

I agree that adding performance test should be an ACC when creating new endpoint, but I have a feeling that this topic is about already existing endpoints that lack performance tests.

In my opinion we should avoid creating tickets like OLMIS-3211, where we both create the performance tests and improve the performance of like 10 endpoints. I feel we should have split that ticket into several smaller ones, one for each endpoint or leave the performance improvement part out of it.

I think that the best approach for now is to implement easy performance fixes within the "create performance test" ticket and create separate ones for endpoints that require bigger reworks.

Best regards,
Nikodem

To post to this group, send email to openl...@googlegroups.com.