Closed (fixed)
Project:
Drupal.org customizations
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
23 Sep 2010 at 21:30 UTC
Updated:
23 May 2014 at 18:23 UTC
Jump to comment: Most recent
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
Comment #1
dwwnnewton and I just discussed this and I'm going to fix with some custom caching in here.
Comment #2
dwwActually, 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
Comment #3
nnewton commentedI've installed this module on a dev site and cached the project_index view. So far this is working really well.
-N
Comment #4
nnewton commentedAdding issue tags
Comment #5
drummLet 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.
Comment #6
nnewton commentedActually 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?
Comment #7
dwwWe 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.
Comment #8
nnewton commentedBelow is my first shot at this, for the project_index view. RFC?
Comment #9
basic commentedThis expire times look good to me, if they're not long enough we can always bump them up.
Comment #10
dwwviews gets it right if you leave this crap out:
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.
Comment #11
nnewton commentedRerolled:
Comment #12
nnewton commentedAdding this as well to declare the new requirements for this:
Comment #13
nnewton commentedCommitted