Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 4 of 4
  1. #1
    Senior Member
    Join Date
    Jul 2010
    Location
    Oz
    Posts
    361

    Which cache to store non-persistent data for a short time?

    Hi.

    I haven't used any cache up to now but now I need to store some client-specific data (array or hash) temporarily for a short time: 15 minutes for the bigger data set (about 3-5KB if saved as a plain text file or 6000-7000 characters) and no more than 60 minutes for the small one).

    So I know there are different ways to store non-persistent data in LMS but I don't know their limitations or which one is suited best for which use case.

    Code:
    $client->modeParam
    Seems to have been around for a long time.

    Code:
    Slim::Utils::Cache
    Probably the default way to cache stuff. Writes to cache.db file unless I'm mistaken.

    Code:
    $client->pluginData
    Can be used to cache stuff. Only for very small data sets?

    Code:
    Tie::Cache::LRU
    Probably for very small data sets. Is this an option at all (for the future)? Module page gives the impressions it's legacy/unsupported/deprecated.

    So if you have used any of these and know about their limitations or any requirements I'd appreciate your opinion/recommendation.
    Thanks.
    Plugin repositories: Ratings Light •••• Visual Statistics •••• Use Comment Tag Info •••• Dynamic Playlists 3 FAQ •••• Custom Skip 3 FAQ

  2. #2
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,666

    Which cache to store non-persistent data for ashort time?

    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.

  3. #3
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    1,250
    Quote Originally Posted by afriend View Post
    I haven't used any cache up to now but now I need to store some client-specific data (array or hash) temporarily for a short time: 15 minutes for the bigger data set (about 3-5KB if saved as a plain text file or 6000-7000 characters) and no more than 60 minutes for the small one).
    I'm using Cache::MemoryCache (for generic data) and Memoize (for subroutine results, can be client-specific )
    Both work well in a plugin.
    Various SW: Web Interface | Text Interface | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | Ambient Noise Mixer | DB Optimizer | Image Enhancer | Chiptunes | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  4. #4
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    21,041
    It seems Michael answered this post here.

    https://forums.slimdevices.com/showt...=1#post1038722

    plugins which I deal with, want to cache URL responses so use Slim::Utils::Cache. URL responses can be large and disk based cache is OK as speed of the cache just needs to be faster than network delay.
    Last edited by bpa; 2021-11-22 at 02:33.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •