2021-11-08 Capacity Planning Meeting





Discussion items

Time reservedDescriptionPresenterDetails/Comments
15 minutes (we need to start with this agenda item because Charlotte needs to be at another meeting)Inventory improvements for Kiwi

Charlotte has identified four Inventory user stories that will benefit larger institutions that have slow queries.  The tickets are:

UIIN-785 - Getting issue details... STATUS blocked by MSEARCH-221 - Getting issue details... STATUS

UIIN-786 - Getting issue details... STATUS blocked by MSEARCH-222 - Getting issue details... STATUS

UIIN-789 - Getting issue details... STATUS blocked by: MSEARCH-219 - Getting issue details... STATUS

UIIN-791 - Getting issue details... STATUS blocked by: MSEARCH-220 - Getting issue details... STATUS

There is also mod-search work that needs to take place first by the Falcon Team. 

The new work is a follow of issues reported by Cornell:

MODINVSTOR-740 - Getting issue details... STATUS  

MODINVSTOR-741 - Getting issue details... STATUS

It would be best for Cornell and Chicago if these changes were implemented in Kiwi rather than waiting for Lotus.  Would it be possible to do these user stories as a hot fix to Kiwi?   Or delay Kiwi until these are completed?

15 minutes

Status update

+ Establish timeline for Juniper HF4

10 minutesRemoval of ranking

Only 6 institutions are actively ranking right now (see info here).  Cornell, one of the six, is concerned about not having this data available in JIRA because this is how they are keeping track of which features we care most about.  They have asked that their ranks remain longer than until January as the PC will most likely not have an alternative by then.  I would like to propose that we export the data for the 21 institutions that are not actively ranking, and leave the six that are until we have an alternative solution. 

Decision:  We will leave the ranking fields the way they are for now.  Will re-address this after the PC has come up with an alternative.  We will not add any new sites.

Will be a separate meeting!PTFHolly Mistlebauer

Cornell has some scale concerns...

Data import: 

  • FOLIO has a page outlining the supposed capabilities and limits of data import that has no connection to reality unless there is minimal activity happening in the library. There is no way we can create 50k at a time or update 5k. https://folio-org.atlassian.net/wiki/display/FOLIOtips/0-Recommended+Maximum+File+Sizes+and+Configuration
  • Cornell staff members have asked repeatedly to be able to see how PTF is testing data import and have not been able to. A rancher environment is being set up for metadata management SMEs but it has been decided that environment will not have more than 50k records on it. A separate environment for performance testing “exists” but isn’t something we have access to. Data import is not a simple process and the type of updating you are doing can have significant impact on the performance. Our feeling is that the PTF tests are too often the simplest scenarios. In some cases, updates aren’t tested at all, only creates.


  • Cornell has ongoing concerns with performance after creating or updating a lot of inventory data – EBSCO has to repeatedly vacuum our database.

With regard to scale issues currently in the process of being resolved...

  • Are there appropriate tests to make sure we keep acceptable performance and don’t see regressions?
      • Data import logging – the log pages are almost unusable in Cornell’s tenant because the query is so slow.
      • Received pieces in orders – Cornell had more pieces per record than developers anticipated so we can’t see most recent pieces
      • Display of holdings/items – Interacting with several of our large holdings is currently difficult or impossible in Iris (fix in Kiwi https://folio-org.atlassian.net/browse/UIIN-1560)
      • What will it take for us to get to sub-second circulation actions? Is there infrastructure to keep track of how changes affect the performance of key operations like in realistic scenarios?