Changes between Version 30 and Version 31 of Ticket #590
- Timestamp:
- 09/09/13 13:20:02 (3 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #590
- Property Total Hours changed from 11.7 to 12.45
-
Ticket #590 – Description
v30 v31 5 5 I also note that many of these cleanup operations will also help make the move to D7 smoother and better. 6 6 7 = Proposed fixes =7 = Summary of fixes and status = 8 8 9 9 === To do: depeding on spare time (JK to monitor, EM to confirm) === 10 '''C) Find Variable table writes and kill them''' -- 3-8 hours, medium reward, low risk -- Per item 9 below, I see plenty of SELECT * FROM variable calls, which imply a cache clear due to a variable being set. In normal use variables shouldn't be set (admin screens tend to do this), so I'd like to try to see what module it causing this and patch/remove it. 10 '''C) Find Variable table writes and kill them''' -- 3-8 hours, medium reward, low risk -- Per item 9 below, I see plenty of SELECT * FROM variable calls, which imply a cache clear due to a variable being set. In normal use variables shouldn't be set (admin screens tend to do this), so I'd like to try to see what module it causing this and patch/remove it. Will need to run {{{grep -R "variable_set() * > ~/static/variable_set-calls.txt" in the {{{sites/all}}} directory to generate a list, then trawl though it to find candidates/bad modules practice. 11 11 12 '''G) Enable ESI (Edge Side Includes) integration module, ensure Drupal renders only what it needs to ''' 3-8 hours, high reward, medium risk -- BOA packages the [https://drupal.org/project/esi ESI (Edge Side Includes integration) module], which makes NginX cache the whole page (as it does now), but also for user-logged in pages (which it does for 5 seconds since the page data changes). This means Drupal renders the ESI component (blocks, panels panes) that are have user-specific data in. Potential boost quickly, but will need time to tweak settings to get best from this across whole site. See [https://tech.transitionnetwork.org/trac/ticket/590#comment:4 comments in 4 & 5 below for discussion] , should be done after proposal F, above.12 '''G) Enable ESI (Edge Side Includes) integration module, ensure Drupal renders only what it needs to ''' 3-8 hours, high reward, medium risk -- BOA packages the [https://drupal.org/project/esi ESI (Edge Side Includes integration) module], which makes NginX cache the whole page (as it does now), but also for user-logged in pages (which it does for 5 seconds since the page data changes). This means Drupal renders the ESI component (blocks, panels panes) that are have user-specific data in. Potential boost quickly, but will need time to tweak settings to get best from this across whole site. See [https://tech.transitionnetwork.org/trac/ticket/590#comment:4 comments in 4 & 5 below for discussion]~~, should be done after proposal F, above~~. 13 13 14 14 15 15 === New, to run past Ed === 16 '''J) Convert inline PHP into module code and features''' -- various parts ( 2-3 hours for block code; 4-8 hours to make Features be used across site), high reward, low risk -- {{{Eval()}}}uated code is much slower than PHP in files... We have a few blocks and many views that are loaded from the database and evaluated. Ideally the blocks would be moved to the 'Transition Extras' module, and the views would be pushed into features. This work is good to do for maintainability and D7 upgrades, too.16 '''J) Convert inline PHP into module code and features''' -- various parts (1-2 hours for block code; 4-6 hours to make Features be used across site), high reward, low risk -- {{{Eval()}}}uated code is much slower than PHP in files, especially since it can't be accelerated by APC or Zend Opcode cache... We have a few blocks and many views that are loaded from the database and evaluated. Ideally the blocks would be moved to the 'Transition Extras' module, and the views would be pushed into features. This work is good to do for maintainability and D7 upgrades, too. 17 17 18 18 19 === Done already===19 === Done === 20 20 '''A) Remove spam taxonomy entries''' ~~1/2 hour, Low risk, low reward -- See item 8 below. A simple delete from taxo term table where length > 50 is worth doing IMHO, and nothing I saw that would be clobbered is not spam.~~ 21 21 … … 32 32 '''K) Add & enable Views Lite Pager on big views.''' ~~1 hour, low risk, low reward -- Using this module stops a heavy count query on views with pagers -- recommended for large sites.~~ 33 33 34 34 35 === On hold for now === 35 '''B.2) More Taxonomy cleanup''': 2 hours, Low risk, low reward -- try to merge terms with the same names. 36 '''B.2) More Taxonomy cleanup''': 2 hours, Low risk, low reward -- try to merge terms with the same names. Ed to consider doing this when he's feeling anti-spammy. 36 37 37 38 '''E) Review site features, kill what we don't really need''' Low risk, '''game changer''', care needed, medium reward -- Let's start reviewing the site and make a short-list of things that have had their day. Ed, do you want to drive this on your return. 38 39 * '''E.1) Remove 'Geographic region' and related taxonomy and Hierarchical Select modules''' 1 hour, low reward, low risk -- never really been used and is effectively a duplicate of the location field. let's kill it! 39 40 * '''E.2) Kill Microsites and the Forums''' -- 3 hours, low risk, '''game changer/needs confirmation''', high reward: -- then remove OG and Forum modules. In D6 these are known to be performance killers. We could alternatively migrate the forum to a simpler setup (not using forum module) that leverages Disqus or other services to offload comments and moderation. Either way, the handful of people using the CMS feature should be migrated to Open Atrium if they need such features. 41 * '''E.3) Ed to add his options for clear out'''...
