panels_mini_load needs caching. If using the context module it can add over 500ms of time to a page load.

Comments

mikeytown2’s picture

Status: Active » Needs review
StatusFileSize
new3.36 KB

Fairly certain that this can be done in a better way; but I'm seeing a 700ms improvement so that's good.

mikeytown2’s picture

Title: panels_mini_load » panels_mini_load & friends need caching
mglaman’s picture

Status: Needs review » Needs work
+++ b/panels_mini/panels_mini.module
@@ -145,6 +145,20 @@ function panels_mini_block_list_alter(&$blocks) {
+
+  $count = 0;
+  foreach ($blocks as $key => $block) {
+    if ($block->module != 'panels_mini') {
+      // This block was added by a contrib module, leave it in the list.
+      continue;
+    }
+    $count++;
+  }
+  if ($count > 15) {
+    // Load add at once to save time.
+    panels_mini_load_all();
+  }
+

Not 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.

mikeytown2’s picture

Thanks 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.

mglaman’s picture

mikeytown2, 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.

damienmckenna’s picture

Issue tags: +Performance
damienmckenna’s picture

Status: Needs work » Needs review
StatusFileSize
new3.09 KB

Any 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:

      $output = cache_get_multiple($cids);
      foreach ($output as $mini) {
        if (!empty($mini->data)) {
          $mini = $mini->data;
          $cache[$mini->name] = $mini;
        }
      }
      if (empty($cids)) {
        return array_filter($cache);
      }

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.

mikeytown2’s picture

I'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.

What's the rationale for checking if the $cids were empty before returning $cache?

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.

joelpittet’s picture

Status: Needs review » Needs work

We're currently having to flush all the caches when we edit a panel; sorta getting old.

Is 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!

joelpittet’s picture

FYI saved around 60ms on panels_mini_load! Beauty

mikeytown2’s picture

Status: Needs work » Needs review
StatusFileSize
new3.48 KB

Added in a cache clear to the patch

joelpittet’s picture

Status: Needs review » Reviewed & tested by the community

Been using this patch for some time. Huge fan:)

natew’s picture

We have been using the patch from #11 for awhile now without issue.

  • japerry committed 1432d0c on 7.x-3.x authored by mikeytown2
    Issue #2391073 by mikeytown2, DamienMcKenna, joelpittet:...
japerry’s picture

Status: Reviewed & tested by the community » Fixed

Patch 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.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

japerry’s picture

Well.. never trust Joel again! ;)

joelpittet’s picture

LOL, I only get one?

Anonymous’s picture

StatusFileSize
new841 bytes

Sorry 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.

joelpittet’s picture

@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.