Hi guys,

Looking a the D&E page, it would appear that while most of the blocks on this page are actually solr facet driven, the module list is actually a view embedded in the page. This query is actually fairly nasty:


|  1 | SIMPLE      | project_projects                                    | index  | PRIMARY                                                                        | PRIMARY | 4       | NULL                                | 7148 | Using index; Using temporary; Using filesort |
|  1 | SIMPLE      | node                                                | eq_ref | PRIMARY,vid,node_type,node_status_type,nid,tracker_global,node_status_type_uid | PRIMARY | 4       | loadtest.project_projects.nid       |    1 | Using where                                  |
|  1 | SIMPLE      | project_release_supported_versions_project_projects | ref    | PRIMARY                                                                        | PRIMARY | 8       | loadtest.project_projects.nid,const |    1 | Using where; Using index                     |
|  1 | SIMPLE      | term_node                                           | eq_ref | PRIMARY,vid                                                                    | PRIMARY | 8       | const,loadtest.node.vid             |    1 | Using index                                  |

I know we have to support the version filter on this, but could we cache the view results per filter?

-N

Comments

dww’s picture

Assigned: csevb10 » dww

nnewton and I just discussed this and I'm going to fix with some custom caching in here.

dww’s picture

Assigned: dww » drumm
Status: Active » Needs review

Actually, upon further discussion, we want to consider if we should just deploy http://drupal.org/project/views_content_cache on the d.o infra and use that to solve this problem. merlinofchaos pointed me to that when I was talking to him about fixing My Issues performance. When I showed it to nnewton, he said we really might want something like that for other things, e.g. all the views content on g.d.o.

So, @drumm: nnewton wanted me to assign this to you for review to get your sense of if we should invest some time testing the module and seeing if it's suitable for our needs, or if we should just go with the one-off hack of adding our own cache_(get|set) calls in drupalorg.module for rendering this block.

Thanks,
-Derek

nnewton’s picture

I've installed this module on a dev site and cached the project_index view. So far this is working really well.

-N

nnewton’s picture

drumm’s picture

Assigned: drumm » nnewton

Let me know if this assignment doesn't match reality. So far we've been piling enabling new modules into a .._to_.._cleanup jobs in Hudson. Whatever configuration views_content_cache needs should get into drupalorg's view altering, or however else they should be stored in code.

nnewton’s picture

Actually this maybe should be assigned to drumm? Not sure, to move forward here we need to have ctools and the views content cache added and then edit the views in code. Am I wrong?

dww’s picture

We already won the battle for ctools here: #908260: Enable ctools on drupal.org

But yes, we need to deploy ctools and this module, then put some code in drupalorg_project_views_default_views_alter() to modify the default view as needed.

However, since you're the one that's played with this module so far, you're probably in the best position to say what needs to change in the view to get this working.

If you're not up for that, you can just paste/upload an exported view here and I can try to put the appropriate alter() in code.

nnewton’s picture

Below is my first shot at this, for the project_index view. RFC?


diff -u -r1.10 drupalorg.views_default.inc
--- drupalorg.views_default.inc	5 Oct 2010 00:46:07 -0000	1.10
+++ drupalorg.views_default.inc	7 Oct 2010 18:36:38 -0000
@@ -35,6 +35,29 @@
     $filters['tid']['expose']['identifier'] = 'drupal_core';
     $filters['tid']['expose']['label'] = 'Filter by Drupal core version';
     $views['project_index']->display_handler->set_option('filters', $filters);
+    $views['project_index']->display_handler->override_option('cache', array(
+      'type' => 'views_content_cache',
+      'keys' => array(
+        'comment' => array(
+          'changed' => 0,
+        ),
+        'node' => array(
+          'project_project' => 'project_project',
+          'book' => 0,
+          'forum' => 0,
+          'image' => 0,
+          'project_issue' => 0,
+          'packaging_whitelist' => 0,
+          'page' => 0,
+          'project_release' => 0,
+          'story' => 0,
+        ),
+      ),
+      'results_min_lifespan' => '3600',
+      'results_max_lifespan' => '21600',
+      'output_min_lifespan' => '3600',
+      'output_max_lifespan' => '21600',
+    ));
     $views['project_index']->set_display('block_1');
     $views['project_index']->display_handler->set_option('items_per_page', 4);
     $views['project_index']->destroy();
basic’s picture

This expire times look good to me, if they're not long enough we can always bump them up.

dww’s picture

views gets it right if you leave this crap out:

+          'book' => 0,
+          'forum' => 0,
+          'image' => 0,
+          'project_issue' => 0,
+          'packaging_whitelist' => 0,
+          'page' => 0,
+          'project_release' => 0,
+          'story' => 0,

and I tend to purge those from default views to avoid bloat and confusion on other sites with different node types. granted, this is d.o-specific altering, so the cross-site concern isn't valid, but we don't need to bloat the files nonetheless.

Otherwise, looks fine to me.

nnewton’s picture

Rerolled:


--- drupalorg.views_default.inc	5 Oct 2010 00:46:07 -0000	1.10
+++ drupalorg.views_default.inc	8 Oct 2010 17:42:14 -0000
@@ -35,6 +35,21 @@
     $filters['tid']['expose']['identifier'] = 'drupal_core';
     $filters['tid']['expose']['label'] = 'Filter by Drupal core version';
     $views['project_index']->display_handler->set_option('filters', $filters);
+    $views['project_index']->display_handler->override_option('cache', array(
+      'type' => 'views_content_cache',
+      'keys' => array(
+        'comment' => array(
+          'changed' => 0,
+        ),
+        'node' => array(
+          'project_project' => 'project_project',
+        ),
+      ),
+      'results_min_lifespan' => '3600',
+      'results_max_lifespan' => '21600',
+      'output_min_lifespan' => '3600',
+      'output_max_lifespan' => '21600',
+    ));
     $views['project_index']->set_display('block_1');
     $views['project_index']->display_handler->set_option('items_per_page', 4);
     $views['project_index']->destroy();
nnewton’s picture

Adding this as well to declare the new requirements for this:

--- drupalorg.info	7 Oct 2010 17:48:46 -0000	1.5
+++ drupalorg.info	8 Oct 2010 18:55:02 -0000
@@ -5,4 +5,6 @@
 dependencies[] = jquery_ui
 dependencies[] = homebox
 dependencies[] = materialized_view
+dependencies[] = ctools
+dependencies[] = views_content_cache
 core = 6.x

nnewton’s picture

Status: Needs review » Fixed

Committed

Status: Fixed » Closed (fixed)
Issue tags: -drupal.org redesign, -drupal.org redesign project, -drupal.org redesign sprint 5

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

  • Commit c66da3f on 6.x-3.x, 7.x-3.x-dev by nnewton:
    #921124 - by nnewton: Enable views content caching of the project_index...