| 10 | | |
| 11 | | '''N) Replace Admin Menu 1.x with 3.x''' 5 mins, high reward, low risk -- done when #582 happens, could be the cause of some load spikes as it occasionally goes made and does 2000-5000 queries! |
| 12 | | |
| 13 | | === New, and to run past Ed === |
| 14 | | '''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. See: http://2bits.com/api/abuse-drupal-best-practices-your-own-peril-poor-performance.html and http://2bits.com/articles/free-your-content-php-moving-php-code-out-blocks-views-and-nodes.html |
| 15 | | |
| 16 | | '''O) Stop making so many URL aliases for non-relevant pages, clean up url_alias table''' -- 1/2-1 hour, medium reward, only risk is that some links might break -- though given what is proposed that's unlikely. E.g. |
| 17 | | * 1,772 entries for: people/[name]/feed |
| 18 | | * 1,837 entries: user/[name]/contact |
| 19 | | * What's the point of people/[name] AND user/[name] being aliased when we always link to /people/*..? Taking out all /users/* aliases = 17,358 entries saved! |
| 20 | | |
| 21 | | === To do: depending on spare time (JK to monitor, EM to confirm) === |
| 22 | | '''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. |
| 23 | | |
| 24 | | '''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~~. |
| 25 | | |
| 45 | | === On hold for now === |
| | 36 | |
| | 37 | |
| | 38 | == Postponed to Pre D7 migration tasks (pending other ticket == |
| | 39 | '''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. See: http://2bits.com/api/abuse-drupal-best-practices-your-own-peril-poor-performance.html and http://2bits.com/articles/free-your-content-php-moving-php-code-out-blocks-views-and-nodes.html |
| | 40 | |
| | 41 | |
| | 42 | === To do: depending on spare time (JK to monitor, EM to confirm) === |
| | 43 | '''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. |
| | 44 | |
| | 45 | '''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~~. |
| | 46 | |
