Transition Technology: Ticket Query

#590: Drupal performance improvements

jim — Fri, 06 Sep 2013 10:27:27 GMT

This ticket is to track the work and changes done within the Drupal sphere in relation to performance enhancements done since #585.

More information is needed and will come when ticket:586 New Relic Monitoring for BOA is completed.

I also note that many of these cleanup operations will also help make the move to D7 smoother and better.

Summary of actions and status

TODO

O) Stop making so many URL aliases for non-relevant pages, clean up url_alias table -- 1/4-1/2 hour, medium reward, only risk is that some already broken links might break... Per chat with Ed, only these will be removed (plus releated tweaks to Pathauto settings):

3,579 entries where src = node/%/feed
1,856 entries where src = user/%/contact
= 5,435 or ~11% of entries in url_alias

L) Review slow query log, explain queries, tweak as necessary/flag poorly behaving modules. 2-4 hours, high reward, low risk... Keep looking at the slow query log and adjust Drupal or find patches as necessary. ALSO related Reduce your server's resource usage by moving MySQL temporary directory to tmpfs... Have opened ticket for this: #591 for Chris.

Done

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.~~

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.

D) Review Views caching ~~1 hour, low risk, high reward -- Utilise Views Content Cache this was done a while back but I think -- done (task 12) in comment 21.~~

F) Force blocks caches to cached appropriately (and be rendered/included only as needed) 1-2 hours, medium reward, low risk -- BOA packages the Block Cache Alter, which makes sure Drupal only renders blocks when needed. Potential small but nice boost quickly in whole site. -- per comment 22, block caching is disabled by other modules so this will have to go on hold for now.

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...

I) Re-enable block caching. 2-6 hours, high risk, high reward -- Per comment 24, a module (probably Content Access) is stopping Drupal caching blocks, which for some of them means a fair amount of pointless overhead. We need to somehow get around this and get blocks cached if possible. R&D mainly, perhaps with some hacking/patching - but I'd stop short of doing this if so.

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.~~

M) Take control of Cron, and maximise time pages are cached for. .25h, high reward, low risk -- Cron is wiping the page cache, so we need to install https://drupal.org/project/elysia_cron so we can clear the page less often, and run other things when we want and the site is quieter. Now need per minute resolution set to get the best, see comment 33 and 34 for more...

N) Replace Admin Menu 1.x with 3.x -- will happen when #590 occurs, marking complete here -- ~~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~~~~

#644: AWstats Nginx config breaks aegir

jim — Mon, 09 Dec 2013 16:46:05 GMT

Since the last update we've had a silent ngnix error that means http://tn.puffin.webarch.net was not available.

I restarted nginx and got:

[  ok  ] Stopping Nginx Server...:
[ .... ] Starting Nginx Server...:nginx: [emerg] "log_format" directive is not allowed here in /etc/nginx/nginx.conf:28

Which equates to the AWstats entry which is now commented out per:

# log for awstats
#log_format apache '$remote_addr - $remote_user [$time_local] "$request" '
#                   '$status $body_bytes_sent "$http_referer" '
#                   '"$http_user_agent"';
#access_log         /var/log/nginx/awstats.log apache;

I/we need access to aegir more than AWStats, so I've commented out the lines above and restarted nginx. Aegir is back and working well.

This ticket is to find the correct log_format for modern nginx versions and reinstate AWstats -- assigning to Chris as a low priority thing.

#582: TN.org platform and sites

jim — Mon, 02 Sep 2013 09:30:02 GMT

The TN.org platform and Drupal site updates are to be tracked in this ticket.

Current PROD platform build = P009 Current STG platform build = S010

Updates pending:

SECURITY UPDATE - NO RISK: Pressflow core 6.30 is due, but the security holes fixed do not affect us, low priority. Platforms: present in S010, but not in P009.

#606: Site upgrade tasks -- pre-migration cleanup

jim — Fri, 11 Oct 2013 12:00:13 GMT

This ticket is to track the issues left over from #590 that need to be considered and tackled prior to migrating the site from D6 to D7 (or 8).

Please feel free to add as needed, but sticky to the

C) Cleanup: List of features we don't really need

Ed to add his items to following list... Need rational and alternative approaches for each.

C.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!
C.2) Kill Microsites and the Forums -- The handful of people using the CMS feature should be migrated to Open Atrium if they need such features.
C.3) Remove forums -- We could migrate the forum to a simpler setup (not using forum module) that leverages normal commenting, or even Disqus or other services to offload comments and moderation. Also encourage user-submitted ocontent and promote that if it's good or gets interesting debate.

D) Key development tasks

D.1) All inline PHP must be moved to modules and features -- This has great benefit for management, maintenance and developers. 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

D.2) Build in ESI (Edge Side Includes) support from the outset, ensure Drupal renders only what it needs to -- BOA packages the 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 comments in 4 & 5 below for discussion~~, should be done after proposal F, above~~.

E) Key editorial tasks

E.1) More Taxonomy cleanup -- try to merge terms with the same names, clear out spammy terms, general spit-and-polish. Ed plus team of busy interns to do this when the time is right.

Z) old stuff for reference; tasks from #590 rendered pointless by move

Z.1) Find Variable table writes and kill them -- seeing 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.

#671: Replace core Search module with Apache Solr

jim — Sat, 11 Jan 2014 21:11:14 GMT

Issue & background During work on #610, it was discovered that of a 1/4GB database dump for TN.org, ~80% (180Mb) of it was related to the Drupal 6 core Search module.

It's worth noting this was raised when we migrated the site to the Puffin server in March 2013, but it's generally the case that the core Search module does not scale easily beyond a few thousand nodes.

www.transitionnetwork.org has 23,803 nodes at time of writing -- this is probably approaching the sensible limit of the core module's capability.

Note also, any future D7 or D8 version of the site would also hugely benefit from using Solr, so the server config part is time well spent.

Proposed solution

Add the Apache Solr option to BOA, re-run the installer to get it installed and configured automatically.
Add the ApacheSolr module and any related required modules to the TN D6 makefile -- it's not clear if the 6.x-3.x branch or 6.x-1.x branch is the right choice at present.
Build a new platform containing these modules, migrate a clone of STG to it.
Enable the modules, configure them, disable core Search.
Create a feature that wraps up config for Solr and required modules. Add to Git, add reference to feature to makefile
Test, tweak, repeat 3 & 4 & 5 as needed.
Migrate PROD to the new plaform, enabled feature, index site.

This could be parked until D7/8 migration, or not... Ed's call.

#488: Set up Dev/Test and update CodeManagementReleaseProcess for new Aegir, Git, Drush make approach

jim — Mon, 04 Feb 2013 19:07:31 GMT

This page is now out of date... https://tech.transitionnetwork.org/trac/wiki/CodeManagementReleaseProcess

This ticket is to update this with a new version, and set up Dev and Test environments, documenting all as we go.