Re: Which cache to store non-persistent data for a short time?
Michael Herger <slim-b/[email protected]>
| Newsgroups | gmane.music.equipment.slimdevices.devel |
|---|---|
| Message-ID | <[email protected]> |
I select depending not only on the data size, but also eg. how often it's being accessed. > $client->modeParam I'm not even sure about this one, but IMHO it's legacy and shouldn't be used. > Slim::Utils::Cache That's what I'd use for large amounts of data, and if the data isn't often read. It's disk I/O which is slow and keeps the disk busy. > $client->pluginData That's what I'd prefer if eg. a value would be needed often. I often use it for client specific data, rather than keeping it in a global variable. In particular if that data is read regularly. Let's take the example of metadata for a remote streaming track: - the ProtocolHandler's getMetadataFor() is polled every few seconds for the currently playing track, if you're using the web UI. Thus I'd store the data for that track in $client->pluginData - the same protocol handler sometimes requests metadata for all tracks currently in the queue. That's not requested that often, and is a lot more data (# of tracks times the data size per track). Therefore I'd store this in the disk cache, as it could be re-used in a future session, too. > Tie::Cache::LRU That's what I'd use for small sets of data which are not client specific, and which change often, and which would update every now and then, without the previous data being useless immediately. It helps me keeping multiple values around for a while, without a need to manage overall size manually. Things would drop off the list after a while. Keep in mind that this module is slower than pluginData, as the latter is simply a ref to a hash, whereas Tie::Cache::LRU has logic to expire things etc. And yes, it's rather old. But LMS is using it and its siblings all over the place... All but Slim::Utils::Cache are in-memory: faster, but higher memory consumption, and they don't survive a restart.