Changes between Version 10 and Version 12 of Ticket #590


Ignore:
Timestamp:
09/06/13 18:09:13 (3 years ago)
Author:
jim
Comment:

Thanks sir. Updating description...

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #590

    • Property Add Hours to Ticket changed from 0.65 to 0.15
    • Property Total Hours changed from 4.6 to 4.75

  • Ticket #590 – Description

    v10 v12  
    66 
    77= Proposed fixes = 
    8 Ed, please confirm you'd like me to do these, or if you need more info. 
    98 
     9=== Agreed to do by Ed === 
    1010'''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. 
    1111 
    1212'''B) Try a Taxonomy Cleanup''':  3 hours, Medium risk, medium reward -- style module to try to merge terms with the same names and clean up the link tables back to nodes. Further, we can remove any taxonomies or relations to certain CTs that don't really add value. 
    1313 
     14'''D) Review Views caching''' 1-2 hours, low risk, high reward -- this was done a while back but I think 
     15 
     16'''F) Force blocks caches to cached appropriately (and be rendered/included only as needed)''' 1-2 hours, medium reward, low risk -- BOA packages the [https://drupal.org/project/blockcache_alter Block Cache Alter], which makes sure Drupal only renders blocks when needed. Potential small but nice boost quickly in whole site. 
     17 
     18 
     19=== To do once above done if time good (JK to monitor, EM to confirm) === 
     20'''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. 
     21 
     22 
     23=== Done already === 
     24'''H) Remove CustomError module all together''' ~~1/2 hour, low risk, low reward -- We should take out the PHP code from the 403 section of CustomError and put it into a simple page entry. See comment 6 below as this has happened for 404s (which need no PHP). We can then remove the CustomError module all together, saving lots of sessions. I would go ahead and do this but since the 403 page has various displays depending on user type, I wanted to raise it here as it *may* have side effects. Or not...~~ 
     25 
     26 
     27=== On hold for now === 
    1428'''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. 
    15  
    16 '''D) Review Views caching''' 1-2 hours, low risk, high reward -- this was done a while back but I think 
    1729 
    1830'''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. 
    … …  
    2032* '''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. 
    2133 
    22 '''F) Force blocks caches to cached appropriately (and be rendered/included only as needed)''' 1-2 hours, medium reward, low risk -- BOA packages the [https://drupal.org/project/blockcache_alter Block Cache Alter], which makes sure Drupal only renders blocks when needed. Potential small but nice boost quickly in whole site. 
    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  
    26 '''H) DONE: Remove CustomError module all together''' ~~1/2 hour, low risk, low reward -- We should take out the PHP code from the 403 section of CustomError and put it into a simple page entry. See comment 6 below as this has happened for 404s (which need no PHP). We can then remove the CustomError module all together, saving lots of sessions. I would go ahead and do this but since the 403 page has various displays depending on user type, I wanted to raise it here as it *may* have side effects. Or not...~~