Re^2: Proposed new behaviour of isGods and isApproved (per session cache) ($NODE in key)

Since we currently have no accessrules that use $NODE, I'd leave $NODE out of the key. If we come up with accessrules that use $NODE, I'd have them set a flag saying to not cache the results.

That should make the cache both smaller and more effective. A hybrid approach would probably be possible (but, since the only specific use for $NODE that I recall hearing isn't needed, I'm expecting uses of $NODE to be exception and probably not much worth caching, so plans to use $NODE extensively would change that).

But more numbers would be interesting.

With the cache only per-page-hit, the size should usually remain small... But I worry that the-thread-not-to-linked-to or some other untested case could balloon things up.

Update: I got the modified patch to apply. So I've got new NodeBase.pm and HTML.pm queued up to be deployed but it's past bed-time so the deploy will wait 'til I can stick around.

- tye

Comment on Re^2: Proposed new behaviour of isGods and isApproved (per session cache) ($NODE in key)

Replies are listed 'Best First'.
Re^3: Proposed new behaviour of isGods and isApproved (per session cache) ($NODE in key) by demerphq (Chancellor) on Sep 01, 2005 at 07:42 UTC
Well, id like to see all of the isJanitorable and CanSdcEdit and nodes of that sort change into accessrules. And in that case I'd expect to see dupe checks. For instance In the SDC nodelet youd do the check once, and then if you were on an SDC page you'd do it again. Im doubtful if we would see multiple $NODE's for the same $USER/$GROUP in a single fetch, but id be unsurprised if we saw multiple fetch for the same USER/GROUP/NODE combination. So from my POV we lose very little by including NODE in the cache and will most likely save ourself a dupe check or two. Anyway, to explain what i have in mind ill say that id like to be able to do stuff like: `if (isApproved($USER,'sitedocclan',$NODE) { ... }` [download] Which would check that the user is a member of sitedocclan and that $NODE is a type editable by SiteDocClan. This would be done by putting an accessrule as the first member of the group whose code only kicked in if the $NODE parameter was defined. Anyway, I guess my point is that id rather cache it all and see if there are issues with the cache than not cache it and later on repatch the code to return it to the current state. Also id be very surprised if nodes like the one you mention even excersize this aspect of the design. I mean their access profile is quite easy to manage. --- $world=~s/war/peace/g	[reply] [d/l]
Re^4: Proposed new behaviour of isGods and isApproved (per session cache) ($NODE in key) by tye (Sage) on Sep 02, 2005 at 07:37 UTC
$NODE in key: 18 cache hits / 64 lookups No $NODE in key: 62 cache hits / 64 lookups In getting this test case ("node=re (patch)") I also noticed that %HTMLVARS is getting many large data structures left in it. So I'll add code to clean that up and deploy this weekend. Sorry, I got started late tonight, so I skipped my stuff so I could at least give you some test results before the next "dry spell" of me sleeping and then doing my day job, and it's already an hour past when I should be asleep. - tye	[reply]
Re^5: Proposed new behaviour of isGods and isApproved (per session cache) ($NODE in key) by demerphq (Chancellor) on Sep 02, 2005 at 08:57 UTC
Ok, at first i was confused by this and now I realize you were looking at the results for the case where searching occurs. Im not sure if this is an ideal case to use for comparison tho. I believe that the search routine uses CanEditNode() is not normal. Try a normal page fetch and see the results there. I think the case where search isnt invoked is by far the more common case, so speeding that up is more important than speeding up search. Having said that obviously you have a point, but i think maybe there is a middle ground to be found where we still cache with node, but more intelligently. IE, if a group does not contain an accessrule then the NODE is not relevent. Anyway, food for thought. :-) Anyway, thanks for exploring this further, I will do more as well. --- $world=~s/war/peace/g	[reply]