I am wondering if anyone has explored ways to improve the performance of deployed content retrieving pins when they're hosted on the same RStudio Connect server.
Our current workflow:
We use RStudio Server Pro and RStudio Connect, both hosted on Azure VMs.
For development, we create pins on RSSP, and publish to the RSConnect server.
Any content we publish on RStudio Connect (markdown, APIs, etc) will access those pins hosted on the same server.
When we pin() something, we define the board's url, which hops outside the VM network, to the external network (network), and back to our RStudio Connect server. That's fine.
For any published content on RStudio Connect that is accessing those pins, instead of making these hops externally, it would be nice to instead access those pins locally.
What I am really looking for here is to improve our API's responses, hosted on RStudio Connect, by removing any unnecessary network calls that would slow down the response times. Appreciate any thoughts and suggestions!
This is a really interesting question - I'm curious to hear what others' thoughts are.
At some point, it would be really cool to have some type of socket or other really fast method of reading pins on Connect. The best that I can come up with today is:
Use the config package to set up code to "change" automatically based on your environment
When R_CONFIG_ACTIVE=rsconnect (the default on Connect) or whatever is configured for your server, change the URL for how you access to something that is fast / internal. I.e. http://localhost:3939. You will have to be careful of any certificate issues that might arise if Connect is listening in SSL, and could also be mindful of other nodes if you are in an HA environment - in some cases you may want to use a url like https://my-internal-load-balancer.
By default, use the "normal" Connect "front door."
The main pain point here will likely be certificates and trust if Connect is listening in SSL. Please let us know how your testing goes!! You could also probably add some timing easily with bench or some other package to get a sense for what the difference is in performance.
Thanks @cole for your suggestion. I had played around with that idea before, but was using https instead of http.
Now I can obtain the pins in question while defining the board as localhost. That results in about a 30% speed increase, from the time of registering the board to grabbing three pins I have stored on the RSConnect server!