Page Comparison

...

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4631

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4634

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4635

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4638

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4651

•  

  Jira Legacy
  server System JIRA serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-4652

Team ILL

•  Type your task here, using "@" to assign to a user and "//" to select a due date

Next steps:Team ILL still needs to conduct spring planning for 52.

The following were notes and was communicated at the top of the page

• Team Parrot will start Sprint 52, but will focus on fixing the performance issue for single approve, and performance testing for convert to order. The main goal is to demonstrate/repair that we have NOT degraded in performance.
• Sprint Q&A: Team Parrot will discuss the performance testing results and day's status.
• Performance Testing & Resolution:
  • Single approve - the fix doesn't quite get us to the performance guidelines. What else could we do?
    • Our baseline for single approve is ~20 seconds overall, so that is what we are aiming for in order to say we have comparable performance. looking at the 3.3.0 numbers, our median value looks to be about ~40 seconds before any fix, so in order for us to get down to ~20 second baseline, we need to reduce by about 15-20 seconds, meaning the “fix” should ideally get down to the low single digits
    • Any solution will require a regression of all requisition test cases (and maybe convert to order).
  • Convert to order - We need to prove we didn't degrade in performance.
    • Everyone needs to test and update performance page with results (testing one convert to order, multiple convert to orders, multiple times)
    • 3.2.1 baseline for convert to order:
      Convert 8 requisitions: 20s (POST /convertToOrder 15s, GET /requisitionsForConvert 2s)
      Convert 1 requisition: 6s (POST /convertToOrder 3s, GET /requisitionsForConvert 2s)
• Additional notes:
  • Sebastian Brudziński - one thought could be to make supply line configuration change for supervisory nodes (which we recently did) in perftest. Do we think that may have an impact on the performance results in perftest when comparing to our baseline?
  • Sebastian Brudziński - an option is to spin up a 3.2.1 perftest, and have the 3.3 perftest for comparison for the convert to order (Chongsun writes up instructions on how and why)
  • Jakub Kondrat can move forward with creating tickets for 

    Jira Legacy
    server System JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 448ba138-230b-3f91-a83e-16e7db1deed1 key OLMIS-3498

     and replicating to other services.
  • Research, collect and record results. Solutions to single approve performance should be reviewed by Sebastian. The goal is to match the baseline or increase performance without impacting too many services which would cause more regression testing.