Baseline Tech Specs
The basic audit template covers some basic technical stats so we can get a bird eye view of how well the site is put together and what type of stack it's running on.
The main goal of this audit is to assess the feasibility of a migration to Pantheon. If the site is already on Pantheon, the site audit tool mostly takes care of these concerns. If the client is receptive and on a decent hosting platform, you might consider installing the site_audit module.
When we rank something red or yellow we need explanations of what these ratings mean in the Notes section. We will also need to change our default recommendations if, for instance, a multisite is a good solution for a client's needs.
Site Audit Template is HERE
Section 1: Server
| Item | How To Find |
| Basic | |
| Web Server | Check the admin/reports/status for Web Server. If Apache, run this to get exact version: /usr/local/apache/bin/httpd -v Ig Nginx, run: nginx -v |
Database | mysql --version |
PHP Version | php --version |
PHP Memory Limit | php -r "phpinfo();" | grep "memory_limit" |
| Security | |
SSH Access | Examine the hosting service; most services do have this. |
SSH Key | Make sure they are using SSH keys for accounts instead of or in addition to a password. |
| Performance | |
Reverse Proxy | Ex: Varnish. On some Linux Distros you can see if varnish exists by running service --status-all On CentOS and other similar Linux Distros, you can check /usr/sbin for services. Or Run: /usr/sbin/varnishd -V Alternatively, see if they have the Varnish module installed (on D6, they'll need to have Pressflow as well) Otherwise, may have to examine the service plan. |
Key-Value Store | Ex: Memcache/Redis: service --status-all Also, you can check the modules page and see if memcache / redis is installed and configured properly. |
Apache Solr | service --status-all OR examine Drupal search settings (should have Apachesolr module and/or Search API) drush pml --no-core --type=module --status=enabled | grep solr |
OpCode Cache | Ex: APC.: service --status-all Also running php -v will give you something like: # php -v PHP 5.5.23 (cli) (built: Apr 2 2015 16:21:21) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies with the ionCube PHP Loader v4.6.1, Copyright (c) 2002-2014, by ionCube Ltd., and with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies The last line will tell you the APC/OPCache |
CSS/JS Aggregation | Check the Drupal performance admin page. |
Page Caching | Check the Drupal performance admin page. |
Section 2: Drupal
| Item | How to find |
| Tools | |
Version Control | Go to the webroot and run "git version" |
Drush | Try running drush in the webroot; if it exists, "drush version" |
| Directory Structure | |
Files Directory Size | Run worth it to see what size is with imagestyle/imagecache directories excluded: |
Database Size | Run then or Run the following query that lists the sizes of all the available databases. SELECT table_schema AS "Database", ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS "Size (MB)" FROM information_schema.TABLES GROUP BY table_schema; |
Other “Files Directories” | See if any other large files exist in the codebase; particularly in the root of the codebase. |
Codebase Structure | Are there non-standard directories? Is all custom code in sites/all/modules (or appropriate multisite directories)? |
Multisite | See if directories exist for multisite in sites/ |
Non-Drupal Code | Custom scripts are often found in the root of the codebase, check there and feel around a bit  |
| Codebase | |
Contrib Codebase Quality | Run hacked module if possible. How are patches documented? |
Custom Codebase Quality | Is the Drupal API used well? |
Theme Layer Code | Is the Drupal API used well? Are templates misused (tons of PHP in templates instead of preprocess functions)? |
| Contributed Modules | With drush installed run this command: drush pml --no-core --type=module --status=enabled | wc -l |
Content Types | Run either: echo "SELECT COUNT(*) FROM node_type" | drush sqlc OR $ mysql -uusername -ppassword databasename > SELECT COUNT(*) FROM node_type; |
Views | Run either: echo "SELECT COUNT(*) FROM views_view" | drush sqlc OR $ mysql -uusername -ppassword databasename > SELECT COUNT(*) FROM views_view; On D6 you can get the list of all views code and db from the views_cache table with the following query: SELECT COUNT(*) FROM `cache_views` WHERE cid LIKE 'views_default:%'; The query only shows views that are not in code. The best solution on D7 is to use drush: drush views-list --status=enabled This will five you a summary at the end of both code and db views. |
Taxonomy | In D6 you can get a table list of Vocabularies, # of terms, and content types used on with the following query: SELECT v.name, COUNT(DISTINCT td.tid) as '# of terms', CONCAT_WS(', ', vnt.type) as 'used on'
FROM
vocabulary v
LEFT JOIN term_data td ON v.vid = td.vid
LEFT JOIN vocabulary_node_types vnt ON v.vid = vnt.vid
GROUP BY v.name
ORDER BY v.vid ASC;
|
| User roles | In D6 display list of roles and users per role SELECT r.name, COUNT(ur.uid) as 'users' FROM role r LEFT JOIN users_roles ur ON r.rid = ur.rid GROUP BY r.name |
Section 3: Kalacare Content Audit
If this client will be moving into Kalacare, we need to do a deeper audit of their content types and custom functionality.
During the audit phase, we should evaluate whether we will be able to support this client effectively. Briefly look at the categories defined in the Kalacare Brief Template and evaluate the difficulty of supporting the client.
Once the client has signed a Kalacare deal, we should perform an in-depth audit with the goal of helping onboard Kalacare agents into the project.
See:
Front-End performance
A lot of drain can happen on the front end, and this can vary per browser. Lots of calls to external JS or iFrames can really slow things down.
A speed test is the best place to start:
Deeper Technical Audit
DRAFT - MATERIAL NEEDS WORK
Some clients who have specific concerns or have a technical background may require further research. Here are some resources that may assist in preparing audits for them:
- Benchmarking with AB and Siege
- Google PageSpeed
- Basic Performance Audit Template
- Performance + Code Audit Template
Section 1: Performance Audit
| Item | How to find |
| Response Times | |
Server Response | This will vary between requests; for a quick idea, load the page in question with the Network tab open and the browser cache disabled and see how long it takes for the initial request of the HTML document to be returned. |
Render time | How long does it take for the webpage to actually render? This is best represented by the red line in the Google Network tab, which represents the "load" js event (when all images, stylesheets, js files, and other assets are loaded). The blue line represents the DOMContentLoaded event and is less important for our purposes. |
| Google Page Speed | What's the PageSpeed Insights score for the URL you're investigating? Use the mobile speed and the desktop speed (mobile/desktop) in the audit. |
| Performance Config | |
Image Optimization | Is the site effectively using image styles to make sure that images are an appropriate size? Bonus points if they have a system in place to handle responsive images. |