panels_mini_load needs caching. If using the context module it can add over 500ms of time to a page load.
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | 2391073-19-dont_load_cache_if_no_cids.patch | 841 bytes | Anonymous (not verified) |
| #11 | 2391073-11-cache_mini_panels_load.patch | 3.48 KB | mikeytown2 |
| #7 | panels-n2391073-7.patch | 3.09 KB | damienmckenna |
Comments
Comment #1
mikeytown2 commentedFairly certain that this can be done in a better way; but I'm seeing a 700ms improvement so that's good.
Comment #2
mikeytown2 commentedComment #3
mglamanNot sure the exact benefit of this? I get that it loads all of the mini panels at once instead of individual calls.
However, why after 15? Why not just invoke panels_mini_load_all() before the foreach(). If it returns empty, we can just skip the foreach through the block list all together, then.
Do you have any benchmarks? Such as using Panels, Why so slow?. Or a way to reproduce? I've been testing and all of our mini panels have been rendering in 0.15ms or so.
Comment #4
mikeytown2 commentedThanks for the feedback. 700ms benchmark from xdebug. panels mini & context cause every mini panel block to be loaded; for us that's around 60 of them, each taking a little over 10ms to load. The 15 is purely arbitrary.
Comment #5
mglamanmikeytown2, thanks for reply! If you don't mind me asking, what are in the mini panels? Often times its the content, not the mini panel.
I think the first half could be useful - on blocks page just do one load to populate static cache at once.
I think there might more at hand. You can send me an email via contact form if you want if its all sensitive.
Comment #6
damienmckennaComment #7
damienmckennaAny further progress on this? I wonder if there are many sites that use a lot of mini panels, e.g. 100 or more?
I noticed the following code:
Does this not assume that $output is not empty? What's the rationale for checking if the $cids were empty before returning $cache?
Basically, could someone please provide comments to explain the logic? Thanks :)
PS, this patch removes the 15 block counter.
Comment #8
mikeytown2 commentedI'll try to spend some time on this next week. It still needs to flush the cache when a panel is edited as well as some other things. We're currently having to flush all the caches when we edit a panel; sorta getting old.
Has to do with the way cache_get_multiple() works. "$cids: An array of cache IDs for the data to retrieve. This is passed by reference, and will have the IDs successfully returned from cache removed." So if $cids is empty that means we have a 100% cache hit rate and don't need to do anything else; skip the rest of the function.
Comment #9
joelpittetIs there one spot to clear the cache when it's edited?
Setting to needs work due to that comment. But thanks for the patch! Noticed I only have one mini panel but it's loading all over the place, even when there are no mini panels on the page!
Comment #10
joelpittetFYI saved around 60ms on panels_mini_load! Beauty
Comment #11
mikeytown2 commentedAdded in a cache clear to the patch
Comment #12
joelpittetBeen using this patch for some time. Huge fan:)
Comment #13
natew commentedWe have been using the patch from #11 for awhile now without issue.
Comment #15
japerryPatch works and I don't see any regressions (functional or performance) while testing. Will sorta have to take Joel's word for it that works better than without the patch. Although, Joel's word is pretty good ;)
Committed.
Comment #17
japerryWell.. never trust Joel again! ;)
Comment #18
joelpittetLOL, I only get one?
Comment #19
Anonymous (not verified) commentedSorry for reviving this old thread but I am getting a postgres error due to this patch:
postgres_1 | ERROR: syntax error at or near ")" at character 79
postgres_1 | STATEMENT: SELECT cid, data, created, expire, serialized FROM cache_panels WHERE cid IN ()
It is because the $cids array is empty. Patch attached.
Comment #20
joelpittet@samspinoy could you post that in a new issue? This one was closed and only maintainers can re-open and generally a new issue is better then multiple commits on the same issue.