Latency issue in the Hours API

[luisgreg99]

Descriptive summary

Sending requests to Alma to get library hours seem to take very long to respond, causing possible latency spikes across other systems (kiosks, room reservation, etc) that hit this API to retrieve hours from Alma.

Expected behavior

The hours API should be optimized for performance so that other systems don't slow down under heavy load.

Actual behavior

Latency spikes have been in the kiosks app. See issue osulp/kiosks#246

Steps to reproduce the behavior

Possible steps:

1. Send a POST request to /hours with a date range i.e ["2018-07-18", "2018-07-22"]
2. Inspect datadog/logs to double check latency

Related work

• Big latency spikes in HoursController#show kiosks#246
• It would be nice to fix Add to DataDog #60 to be able to double check latency in production

[luisgreg99]

I recently found that we can also get open hours via the scope based URL in Alma (currently used for retrieving holiday hours only): https://github.com/osulp/API/blob/master/config/local_env.example.yml#L17-L18

I think we could improve the API performance by consolidating our requests that query Alma and particularly removing requests done via https://github.com/osulp/API/blob/master/config/local_env.example.yml#L16 (this URL in Alma is used to get open hours only).

This work would involve possibly rewriting https://github.com/osulp/API/blob/master/app/services/api/hours_xml_to_json_parser.rb to parse open hours from the XML returned from https://github.com/osulp/API/blob/master/config/local_env.example.yml#L17-L18 instead. Unfortunately, this URL in Alma doesn't support input date ranges in the payload like https://github.com/osulp/API/blob/master/config/local_env.example.yml#L16, but it does seem to return term hours in date ranges that refer to regular open hours. I think these hours could be used by the parser to determine a particular date so that we can still support the ability to query date ranges when sending a POST to /hours.