in reply to performance with mysql / file-caching / hash reference on demand

"Product category pages," which are frequently called-for but rarely change, can also be managed using things like the classic Cache::Memcached. Once you've assembled the necessary (JSON?) information once, you put it the results the cache. Then, before assembling and storing it again, you query the cache first to see if it is already there. You can, if you like, even store complete HTML fragments, ready for immediate display. The "memcached" daemon automatically handles recycling of infrequently-referenced data. Just about every web-site that I am aware of uses this facility routinely for this purpose, and it can have a dramatic positive impact on performance.
  • Comment on Re: performance with mysql / file-caching / hash reference on demand

Replies are listed 'Best First'.
Re^2: performance with mysql / file-caching / hash reference on demand
by derion (Sexton) on May 02, 2021 at 14:53 UTC
    That sounds interesting. Seems a similar approach but storing in memory. My Database having about 4GB should lead to a manageable size of Data for this method. Besides the difference that the information is stored in an even faster way than in a JSON or hashref in a DB the approach seems kind of similar from my point of view. I still do not get the real disadvantage of storing a cached element in a table. Nevertheless Cache::Memcached looks very nice, thank you for that.
Re^2: performance with mysql / file-caching / hash reference on demand
by Anonymous Monk on May 02, 2021 at 15:25 UTC
    Just about every web-site that I am aware of

    meaningless and useless, as usual.