Caching on the API/Application level, using "memoise"

[kamyarkarimi]

We do have a code with "Plumber API" which is hosted/published on the R connect server. The code runs fine with no issues. However, when we initially try to call one of the endpoints (ex using curl), it takes around 30s for the endpoint to respond, but, any calls after that takes around 2s for the endpoint to respond. If we don't make any calls to the endpoint, leave it for 15-20 min, and then come back and make calls again, the same thing happens ...(first call 30s, subsequent calls 2s).

As a result, this made us hypothesize that there is some catching done at the connect server which is perhaps at the session level. When a session is over (or considered to be over after some inactivity), every thing needs to be redone and the catch is gone (as mentioned, this is just our guess/hypothesis from the behavior seen).

I have tried using "memoise" from the "memoise" libraray. It greatly improved the time for the subsequent calls (from 2s to less than 1s). However, no change to the initial call (remained at 30s), which is what we want to improve...

I looked into the article below which talks about catching for Shiny application at the application level, and I think something similar for the "Plumber API: level/application can solve the issue (unless I am missing something big here and the initial 30s improvement cant be done with catching...)

Shiny - Using caching in Shiny to maximize performance

really appreciate your help on this.

[meztez]

Try to do preprocessing outside of your endpoint function so your endpoint do not pay loading time penalty.

Rsconnect will put your api on sleep when it is idle for a while.

[edavidaja]

As you have discovered, caching can reduce the amount of work your application has to do on a second (or subsequent) invocation of a particular function. However, it sounds like your API is taking a long time to start, so you should consider raising the number of minimum processes that Connect serves of your application to at least one. As @meztez suggests, the other thing you can consider doing is reducing the amount of work your API has to do when it starts.