Web development on SSD

Few months ago I've decided to replace my old laptop and invest into a faster one with SSD and 16GB RAM. So far everything is working great, the computer is really fast making me more productive and happy. :)

As I'm a bit worried about the SSD wear-out, I've spent some time researching the topic. While most people say modern SSDs are pretty good at wear leveling, I prefer to be on the safe side and reduce the write operations as much as possible/reasonable.

Since I'm doing Drupal development on Ubuntu 14.04, some of the tips below may not be relevant for you.

General tips for Ubuntu users

There are a number of great resources on how to optimize your SSD on Linux, I've used these:

Specific to web & Drupal development

1. Disable access logs

While access logs are important on a live server, I've never used them on my local machine. Since data is written in these log files every time you refresh a web page on your local computer, it seems to be a good idea to tell apache not to use access logs.

On Ubutnu 14.04 edit the following file: /etc/apache2/conf-available/other-vhosts-access-log.conf and comment out this line:

CustomLog ${APACHE_LOG_DIR}/other_vhosts_access.log vhost_combined

also make sure you don't define the CustomLog directive in your vhost conf files. For an example, see /etc/apache2/sites-available/000-default.conf:

CustomLog ${APACHE_LOG_DIR}/access.log combined

Finally, you'll need to restart apache.

sudo service apache2 restart

Access log files are located in /var/log/apache2, in order to check you've successfully disabled access logging, go to this directory and make sure log file sizes don't increase when you refresh a page on localhost.

Note: Do not disable error logs, they can be pretty useful when you mess things up in your custom modules...

2. Drush updates & backups

By default drush creates a backup of your current modules when updating, so that it's easy to recover from an update if something goes south. During my 4 years of Drupal development, I've never used these backups (fortunately).

At first, I thought about completely disabling this feature, however it seems to be a better idea to store these backups in the /tmp directory. Since I have my /tmp folder mounted on a virtual file system, it won't cause any write actions on the SSD.

The hard way of achieving this:

drush -y up --no-backup # do not backup original files
drush -y up --backup-dir=/tmp # back up to the tmp folder

of course, you'll keep forgetting to add these options to the update command, so what you should do is to create/edit your drushrc.php file and add these lines:

# Uncomment this to disable backup.
# $command_specific['pm-update'] = array('no-backup' => TRUE);
# Backup to the /tmp folder.
$command_specific['pm-update'] = array('backup-dir' => '/tmp');
$command_specific['pm-updatecode'] = array('backup-dir' => '/tmp');

Once this is done, run

drush cc drush

to clear drush cache and your new settings should be working.

Note: Not familiar with drushrc.php? Read the comments in this example file.

3. Put your database on a RAM disk

If you have plenty of ram, you can try mounting your database on a RAM disk, this will not only significantly speed up your database but database changes only rsync-ed to the disk when you turn off your computer.

Bonus tip:

When developing websites, every now and then I'd like to check what emails a website sends. Configuring your local machine to send emails is usually not a good idea, however there is a neat solution to this problem. You can modify PHP to instead of sending emails write them into a file.

Services

Drupal theming and sitebuild

  • PSD to Drupal theme
  • Installing and configuring modules (Views, CCK, Rules, etc.)
  • Theming modules' output

Drupal module development

  • Almost every site needs smaller modules to modify HTML output or override certain default functionalities
  • Developing custom modules

From the blog