[N/A] Per item cachability

[ircmaxell]

I have a site that I have embeded a module into a content item.  The module uses mosrequestparam to adjust its display.  The problem is if I turn on caching, it freezes the calendar where it is.  Would it be possible to be able to turn off caching to a content item?

Here's what I am talking about http://www.bagsofcrap.com/past-items/co ... endar.html

[masterchief]

Page caching needs to be kept light, and that means not having to look at the object that we are displaying to query if we should use cache or not, as that is a performance hit.  You need to look for js based solutions to get around this for dynamic modules in content.

[ircmaxell]

I completely and utterly disagree with you on this.  How much of a performance hit is an if statement?  Store an additional field in the content database, 'cache'.  Then, in the caching function put in if($content->cache = 0) return false;...  What kind of performance hit is that?  Maybe 0.0001 seconds?  Or how about a if(strpos($body,'')!== false) return false;...  That's an extremely fast function... And it would be nice to change cache time per page... 

[masterchief]

Sorry.  I didn't clarify.  The hit is loading the object itself.

In 1.5 the page cache does not touch any data at all.  The "work" to retrieve a single object is small but adds up.  It's at least one query (probably with multiple joins), you then need to instantiate the JParameter object, parse the ini value of the params field, and then you get to the if statement.

It's not a big deal on a 1 hit per minute site, but on sites with several hits per second all the milliseconds add up.

The thing is we cache at the highest possible level - the rendered html output.  At that level the object doesn't exist, so there is no way to check if the data should not be cached.  Great performance but the trade off is you can't have php generated dynamic content.  You can cache further down, but the complexity of the caching regime increases and the effectiveness reduces (for example, Drupal sometimes over-caches to the point that the physical act of checking the caches is more expensive than retrieving the page from scratch).

Does that make sense?

[ircmaxell]

Trust me, I understand performance benifits of caching and the such.  The problem is that some pages either need a shorter TTL, or need NOT to be cached at all, while others should have a long TTL.  Check out my caching component.  It handles all of that (and more) while giving a HUGE performance gain.  The simplest way would be to alter caching times by URLs.  If the URL matches a specific string, then it has x TTL (where if x = 0, then you don't cache the page).  This could be solved by a "caching" plugin.  Pass certain data to the plugin, and let it return what it wants to do... That way without a plugin, there is minimal performance degredataion (as you put it, I don't think that the performance hit is even remotely close to being enough to worry about), but if you want additional functionality, you can extend it.  Some sites have pages that just can't be cached (the data changes to frequently), so what you are saying, is that they can't use cache at all, because to add it would be too much of a performance hit?

[masterchief]

The performance increase is in the tens of percents.  Not insignificant.  I suggest what you should do is have a look at 1.5 in depth and see if you can make some recommendations based on your work.  If you have some good ideas we can discuss them for inclusion in 1.6.

Thanks.

[ircmaxell]

I'd defiantly be up for working for 1.6 (I'm not just asking for a solution, I'm willing to help work towards it), but the lack of this feature makes 1.5's caching a no-go for me (without significant modification on my part)... Every one of my sites uses some level of dynamic abilities within content (maybe one or 2 pages in the whole site), but that means that caching is out for the whole site because I have 2 pages that shouldn't be cached???  I know I'm not the only one with this issue... Every user of my cache component uses the functionality (I know this for a fact, because there are a few components that don't play nice with caching, and they are disabled by default)...  Just because people don't know they need something, doesn't mean they don't need it (I'm sorry if that sounds bad, it's not how I mean it)...

[masterchief]

Yes, that's what I meant.  We can't do anything for 1.5, but any guidance on improvements we could make for 1.6 would be appreciated.  Alternatively, you could also look at what "hooks" could be put in place to allow 3rd-party extensions (caching plugins, whatever) to be used more effectively.  Unfortunately we have to cater for the lowest common denominator most of the time and, yes, specific sites are disadvantaged by that.  If we can extend things a little so you can add specifically tuned caching solutions depending on your site, then I'd be all for that to.