Over in #2123315: Pager does not appear if fields use Views PHP (7.x-1.x) a patch was committed to solve the pager not appearing, so the pager now appears, but performance and memory usage has hit the can.

I haven't been able to understand the intricacies of how the above fix worked, I tried rolling back #2123315: Pager does not appear if fields use Views PHP (7.x-1.x) and tested with #1937364-1: Filter does not respect pagination, it runs through all nodes in a search instead, as I said I don't understand the intricacies, and therefore if this is a valid route to go, but the pager has appeared and performance and memory has improved rather than degraded.

To give you some idea of memory usage and load times.

Before #2123315: Pager does not appear if fields use Views PHP (7.x-1.x) (pager doesn't work):
10 MB + 8 seconds

After #2123315: Pager does not appear if fields use Views PHP (7.x-1.x) (pager works but performance sucks):
535 MB + 15 seconds

With #1937364-1: Filter does not respect pagination, it runs through all nodes in a search instead of #2123315: Pager does not appear if fields use Views PHP (7.x-1.x) (pager works? and performance is great):
10 MB + 7 seconds

Issue fork views_php-2628014

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

MustangGB created an issue. See original summary.

bkat’s picture

In views_php.module, views_php_views_post_build($view) kills the limit/offset in the query and will return all rows thus increasing the page load time.

In my case, it craps out after all memory is consumed by I have a view with 72 pages of 50 items each. The crazy thing is that I don't even have views_php filtering defined for this view. Yes, it kills the query's range even if you just have views_php fields!

Furthermore, I still lose the pager because of

$this->wrapped->total_items = count($this->wrapped->view->result);

and

$this->wrapped->view->result = array_slice($this->wrapped->view->result, $offset, $item_per_page);

int views_php_plugin_pager.inc function updated_wrapped_pager()

PS. I'm on 7.x-2.x-dev but they closed both of the issues on the branch as duplicates of the 7.x-1.x-dev issue

jamesfk’s picture

Hi everyone,

Just to confirm we were hitting the memory issues with the latest release of Views PHP and Search API on Drupal 7:

Search API: 7.x-1.25
Views PHP: 7.x-1.0-alpha3

These latest releases had fully fixed pagers and counts, so we encountered no issues with those at all, but unfortunately, on a site with tens of thousands of nodes indexed, the search pages rapidly became unusable with the internal memory / page limits not being respected.

After trying various combinations of modules and patches, we found the following worked perfectly, patch #1937364-1: Filter does not respect pagination, it runs through all nodes in a search run on the alpha 1 release of Views PHP:
https://www.drupal.org/project/views_php/releases/7.x-1.0-alpha1

This is working perfectly (so far) with the latest Search API modules, so may be useful for anyone else hitting this potentially quite popular edge case.

All the best,
James

skylord’s picture

Version: 7.x-1.x-dev » 7.x-1.0-alpha3
Category: Feature request » Bug report
Status: Active » Needs review
FileSize
4.03 KB

As pointed out previously the cause of performance degradation is that module forces view to load all items not respecting pagers' settings. It surely needed for sorting and filtering but simple field output is not the case. So, i suggest to enable loading of all items only when it's needed - in filter/sort handlers and fields' click-sort. Here is a patch - works great for me.

MustangGB’s picture

Status: Needs review » Needs work

Came a cropper of this, so looked into it again, and came to exactly the same conclusion as skylord.
Amazing patch!

My only comment is the help text This will have huge performance impact as will load full dataset ignoring pager settings, I suggest it might be clearer to say something like This may have a large performance impact as all results will be loaded from the database, and pager limits will only be applied in PHP.

So needs works for the text clarification, but otherwise, I'm liking it a lot.

skylord’s picture

Status: Needs work » Needs review
FileSize
4.07 KB

OK, message changed.

MustangGB’s picture

Status: Needs review » Reviewed & tested by the community

Theory is sound, patch looks good, and works as advertised.

rcodina’s picture

I enclose the patch on #6 adapted to work on branch 7.x-2.x. The only rejected code for patch #6 on branch 7.x-2.x is the following (views_php_plugin_pager.inc.rej):

***************
*** 37,51 ****
        }
      }
  
-     $this->wrapped->total_items = count($this->wrapped->view->result);
-     $this->wrapped->update_page_info();
- 
-     $item_per_page = $this->wrapped->get_items_per_page();
-     if ($item_per_page > 0) {
-       $offset = $this->wrapped->get_current_page() * $item_per_page + $this->wrapped->get_offset();
-       $this->wrapped->view->result = array_slice($this->wrapped->view->result, $offset, $item_per_page);
      }
-     $this->wrapped->post_execute($result);
    }
  
  
--- 39,55 ----
        }
      }
  
+     if (!empty($this->wrapped->view->views_php_query_all)) {
+       $this->wrapped->total_items = count($this->wrapped->view->result);
+       $this->wrapped->update_page_info();
+ 
+       $item_per_page = $this->wrapped->get_items_per_page();
+       if ($item_per_page > 0) {
+         $offset = $this->wrapped->get_current_page() * $item_per_page + $this->wrapped->get_offset();
+         $this->wrapped->view->result = array_slice($this->wrapped->view->result, $offset, $item_per_page);
+       }
+       $this->wrapped->post_execute($result);
      }
    }

Liam Morland made their first commit to this issue’s fork.

Liam Morland’s picture

Version: 7.x-1.0-alpha3 » 7.x-1.x-dev

I have created an issue fork and merge request with the patch from #6.

joseph.olstad’s picture

this project needs a new maintainer , the current maintainers have not been active for a while (look at the project page), I suggest pinging all of them and asking for maintainer priviledges.

Liam Morland’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs reroll
Suresh Prabhu Parkala’s picture

Assigned: Unassigned » Suresh Prabhu Parkala
Suresh Prabhu Parkala’s picture

Assigned: Suresh Prabhu Parkala » Unassigned
Status: Needs work » Needs review
FileSize
4.7 KB

Re-rolled patch #6. Please review.

Liam Morland’s picture

Thank you. I would appreciate it if you would update the issue fork.

Liam Morland’s picture

I'm moving towards making a release. I would like to get this in. The issue fork needs to be rebased and it needs to be tested back to RTBC. Thanks.

skylord’s picture

Reroll from #15 works fine with 7.x-1.0-beta1! Thanks!

skylord’s picture

Found a small bug in #15. Fixed.

Liam Morland’s picture

Status: Needs review » Needs work

Please update the issue fork.

joseph.olstad’s picture

Status: Needs work » Needs review
MustangGB’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs reroll

This is a straight up reroll, so marking RTBC again.

  • Liam Morland committed 9347802 on 7.x-1.x authored by rcodina
    Issue #2628014: Fix performance and memory regression in pager fix...
Liam Morland’s picture

Status: Reviewed & tested by the community » Fixed
MustangGB’s picture

Hurray!

Status: Fixed » Closed (fixed)

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