Implement generic recsys-side recommendation caching
One of the issues currently impacting any recsystems is that if they are not performant enough in responding to recommendation requests, their recommendations are often rejected. This can be difficult to debug or anticipate, especially for contestants, and especially until we have better ways for contestants to test the performance of their recsystems.
This problem even affected the renewal_recsystem.baseline.keywords
sample recsystem, which tended to grow slower over time as it amassed larger datasets for each user.
In 9fc5f452 I fixed some of the underlying performance issues with that recsystem, though the fix is not a silver bullet. So I also added to the recsystem its own caching mechanism, to pre-compute recommendations for the users assigned to it (something we generally have expected contestants to consider doing as well, depending on their recommendation algorithm).
In fact, during our first trial competition I wrote up a recipe for caching recommendations that I suggested to the students for their recsystems; I think two of them implemented it to varying degrees of success.
This recipe is pretty generic and independent of other details of the recsystem implementation. It allows the recsystem to pre-compute recommendations in the background, so that it can send them immediately upon request. In my solution in 9fc5f452 I also added a time-to-live for cached recommendations, so that users don't get overly stale cached recommendations.
Since in practice most contestants will use our Python library (since writing a recsystem completely from scratch can be a bit complicated, particularly w.r.t. handling the network protocols), contestants could easily benefit from getting this functionality "for free" when using the Python framework. This could act as a complement to server-side recommendation caching, which we would also like to add, but recsystem side caching is actually a bit simpler.
So I think I will add this functionality to the base recsystem implementation. I will also add the possibility for contestants to configure this functionality via global variables in their recsystem modules. This could quickly ameliorate some of the problems with the recsystems from the trial competition.