Drupal 7.14

Drupal 7.14 is out and has useful performance improvements plus the usual security fixes. Drupal 7.13 is also available and contains the security fixes without the other improvements.

If you have a complicated web site using many add-modules, apply 7.13 to get the security fixes in place then start a longer term project to test 7.14. Basic Web sites will upgrade direct to 7.14 without problems.

Database changes

7.14 has a list of the individual issues fixed in 7.14. Six of the changes require database changes. When you update your code to 7.14, run update.php to update the database. Very large databases will require a few minutes to apply the changes.

Speed increases

There are not many significant speed increases and you may not see a difference. Some of the changes add indexes to tables to speed up some accesses. One change has a complicated description suggesting the change will only produce a benefit when a specific table has a large number of entries and there is no guide to what benefit you will see at different sizes.

You will get some benefit even if it is not visible. The people developing the performance enhancements are measuring the results. There should be no situation where any of the changes make your site slower.

As an example, http://drupal.org/node/1348758 adds an index that saves time when adding pictures to user profiles. You will not see a difference if you are not using pictures in profiles. Sites using pictures will only see a result when there are many users and a user is adding a picture.

The update to 7.14 should be put ahead of other performance related changes, the content delivery network, memcache, varnish, all the add-on junk creating additional overheads without necessarily solving problems.

Priorities

What is the priority for fixing performance problems?

1. Look in the log entries and fix all PHP errors. They are the worst slow down you can have.
2. Apply Drupal updates like 7.14. When you fall behind, you have to skip testing to catch up.
3. Add memory. Memory is the cheapest improvement.
4. Adjust your configuration to fit the memory. Adjust MySQL to use more because the default is too small.
5. Merge the CSS files in your themes. Most themes have too many files.
6. Move static images to a separate server. let them download in parallel.
7. Now you can experiment with the fancy add-ons that might work for some some pages on some sites.

Memory

Paging (also called swapping) is unnecessary and is bad. Paging is even worse on Linux because Linux dies when it starts paging. All you need to reduce paging is more memory and memory is a cheap resource if you use a good hosting company. Good configuration is better but it takes time and a memory upgrade is a better use of your time.

Most of the other performance improvements need extra memory. When you add an index to a database table, the index works best if the index can sit in memory. Your database software needs enough memory to hold all the active indexes.

The changes in Drupal 7.14 might use an extra megabyte in a small Web site and an extra ten megabytes in a larger site. The small amount of extra code might add a few kilobytes to each page view and is multiplied by the number of pages viewed at the same time. The extra megabyte of database index will be shared across all page views.

After an update of this type, you find a way to measure the paging by the database and increase the database memory until the paging stops. You then look at the memory used by the rest of the system and increase the memory until the paging stops. For some updates, you might have to increase the PHP memory allocation.

Weird fixes

drupal.org/node/1404380 is an example of a weird error where a slight error in one place creates a big performance problem in another part of Drupal. You do not have time to diagnose these types of problems or to measure the impact. Apply the updates to benefit from the hundreds of developers working on these weird problems.

drupal.org/node/966210 started out as a fix for a problem with file management and ended up as a combined Linux/Unix/database confusion. Part of the issue says:
Create two files on your desktop 'tree.jpg' and 'Tree.jpg' in separate folders.
The problem description then suggests you upload both as attachments to a Drupal node. You get an error because part of Drupal treats them as separate files but then stores them in the MySQL database as if they are the same file. Drupal depends on some database weirdness to tell the difference. The fix should change the file reference to treat them as different files so that it does not matter what the database does. Instead they attempt to make MySQL behave the same ways as PostgreSQL. All that code changed without really fixing the problem.

Changes should not depend on a specific database peculiarity. Tree.txt and tree.txt are simply two ways of typing the same name. It is only the different directories that make the files different. If some file systems happen to be broken in a way that lets you store two different files with the same name in the same directory, the file system should be fixed, not Drupal.

When all file systems are changed to make them semantic, Tree.txt and tree.txt will be the same. Drupal will then have to fix the problem Drupal created.

The change to Drupal does remove an error message. I have not researched the code changes in detail, only the descriptions in the issue. The first entries suggest several approaches including sensible ones. The later comments suggest the developers chose a less sensible alternative because it looked easier and they only work on Linux with the broken Linux file system.

Running off track

The method used to identify the files still needs a long term change. That will not happen because the developers are losing interest in Drupal 7 and focussing on Drupal 8, which already has too many changes in progress to arrive in a useful time. This is effectively the same problem you have with Microsoft Windows. They put too many changes in each update. They have to stop fixing errors because of the heavy change workload. The update arrives too late to be useful. Most of the major problems remain in the operating system after the update. Many new problems are introduced. Productivity is not improved.

Drupal 8 is trying to fix presentation issues created by Drupal when Drupal developers ignored the smartphone. Nothing was done to handle smartphones until Apple released the Apple clone of the old HTC smartphone. Drupal 8 is also trying to fix the backend processing problems created by the drupal 7 inclusion of the Fields module. Drupal 8 could be a quick efficient fix for either problem. Instead it will be the 900 pound gorilla trying to pound both problems to death.

Keep up to date

The people testing updates usually keep their systems up to date and test small updates. If you fall behind a few updates and try to catch up with one big update, some of the updates might crash into each other. The best approach is to allocate a day every month to update something, Drupal or add-on modules or the underlying software or your configuration.