Cache the base path of bullet_train when accessing documentation

[gazayas]

I looked into the TODO in the DocumentationSupport module, and although this doesn't fix it, it gives us a speed boost by caching the bundle show bullet_train output.

I can't think of another way right now to access the docs from the gem in the context of a Bullet Train app besides linking to each raw file here on GitHub, but I feel like that would be slower anyways. I'm personally okay with bundle show bullet_train initially if we keep this cache, but I didn't delete the TODO just in case there's another way we want to approach this problem.

[jagthedrummer]

@gazayas I'm curious if we've seen problems crop up due to the lack of caching. I'm a little concerned that there's no timeout on this cache and so once it's cached it could potentially stay around forever. I'm thinking we'd want it to change if a new version of the gem has been installed to a different place.

[gazayas]

@jagthedrummer Good point, I didn't think about version discrepancies, and if we wanted to check for a new version to compare with the cache we'd have to run bundle show again anyways... So, I went ahead and updated the cache to expire in 30 minutes. Do you think that's a good amount of time?

[jagthedrummer]

@gazayas I'm mostly curios if there are documented problems here without the caching. And/or how much of a speed difference does it make? Basically I'm wondering if the juice is worth the squeeze on this one. (With cache invalidation being one of the hard things, and all that.)

[gazayas]

@jagthedrummer I have always felt like accessing the docs on the live website can be a little slow especially due to bundle show being called, but I could be wrong and I don't actually have concrete benchmarks to prove my case 😬 So I'll see if I can come up with some, and we can decide what to do from there!

[jagthedrummer]

@gazayas I just did some very unscientific bench-marking on this and... you were right! Kinda.

It turns out that calling bundle show on every request is kinda slow. When we do it on every request I was seeing local times for /docs/* paths that were consistently in the 220-230ms range.

But, it seems like making a network round trip to the cache, even locally, is close to equally slow. Using your Rails.cache fix I was seeing times consistently in the 190-200ms range.

By memoizing the value in a constant I was seeing times consistently in the 10-20ms range.

Memoizing also has the nice side effect of letting us sidestep the question about how long to cache the value. Every time the server (or any process) is restarted the value will be re-evaluated, which will take care of my concern about us caching an out-of-date path.

[jagthedrummer]

After updating the demo site and deploying it, this PR has made a big difference!

Before:

After:

Good call on trying to optimize it, @gazayas!

[gazayas]

@jagthedrummer Thanks for optimizing this one, and sorry for the delay! I'll be sure to try to use this technique if something similar shows up again!