Add debug log for cached requests in idamClient

[munechika-koyo]

Hello!

Whan I compiled the UDA client, I ran into the following error:

$SRC_DIR/source/client/udaClient.cpp:442:13: error: variable 'num_cached' set but not used [-Werror,-Wunused-but-set-variable]
  442 |         int num_cached = 0;
      |             ^
1 error generated.

To use this variable outside the for loop statement as well, I would like to introduce a debug log to track the number of cached requests in the idamClient function.
I would appreciate it if you could confirm whether this handling is correct.

[stephen-dixon]

Thanks for looking into this. Happy to merge this change.

I did just want to highlight though that a lot of the memcache and filecache caching was a bit experimental and never fully tested or completed. It's not something we use in production at UKAEA, and although we'd like to develop it further, hasn't been top of the priority list for us.

One issue I know of will be serverside caching of structured data (which I doubt you use -- IMAS is all CAPNP types I believe which should work better), but clientside will probably be much more robust.

We're happy to support if this is functionality you're interested in using more and will review PRs and we've also just added a "discussions" tab to this repo which may be a good place we can track any ongoing discsussions on the caching topic in more detail.

[stephen-dixon]

note that this variable num_requests appears to just count the number of cache hits within each bundle of requests for a get or get_batch API call. it doesn't track the number of cached data items or the total cache hits over either client or cache lifetimes. Just to check this is the metric you're interested in tracking.

[munechika-koyo]

Thank you for your prompt response!
Yes, as you mentioned, I am fully engaged with IMAS-related functionalities (client-only tasks) and aim to distribute the libraries required for the IMAS UDA backend.
Therefore, I suggested this change to pass the compilation itself.

I am not familiar with the caching feature, so I'm unsure if I can offer helpful advice.
However, I will contribute as much as I can.

[stephen-dixon]

Oh, in that case I'd suggest making sure you don't have the CMake option for disabling caching unset when you configure your build, -DNO_MEMCACHE=OFF, (NO_MEMCACHE should be ON by default) if you're not using it. Your fix is still good but I don't think that block should compile at all by default.

[munechika-koyo]

I didn't know that!
If libmemcached doesn't provide any performance benefits on the IMAS side, I will opt it out as a dependency, to reduce the size of compiled artifacts as well.
Thanks so much for your advice!

[stephen-dixon]

No IMAS benefits I'm aware of. I think there may be different levels of caching, maybe in the imas uda access layer or the imas plugin, for improved remote-mapping performance within a single client session. But that's something separate.

The use-case for memcached is different, mostly if you have multiple clients all accessing the same (remote) data items e.g. just following an experiment there may be a lot of scientists all analysing the same new data so a cluster-wide cache of recently requested data saves the repeated download time.

[munechika-koyo]

The use-case for memcached is different, mostly if you have multiple clients all accessing the same (remote) data items e.g. just following an experiment there may be a lot of scientists all analysing the same new data so a cluster-wide cache of recently requested data saves the repeated download time.

So, it seems that a UDA server needs to manage the caching system not only on the client side.
Thank you for the detailed explanation.