options { long_hostnames(off); flush_lines(0); perm(0640); stats_freq(0); mark_freq(0); };

1) Windows support of pecl extensions has been non-existent for quite some time.
2) YAST on SUSE 11 doesn’t include support for pecl extensions.

The second of these isn’t a major issue since it is fairly trivial to compile extensions for PHP on linux. Windows systems, however, are not quite so simple. So in order to maintain consistency in the PHP environment between servers I decided to switch to an English-language-only stemmer, the Porter Stemming Algorithm:
http://tartarus.org/~martin/PorterStemmer/

The main drawback is the lack of support for other languages. Fortunately we don’t need that kind of support right now.

Set up your users controller so that it will hash passwords (this will not be done automatically like it would if you were not using scaffolding). Add the following callback method to your users controller:

function _beforeScaffold($action) {
  if (($action == 'edit' || $action == 'add') && isset($this->data)) {
    $this->data['User']['password'] = AuthComponent::password($this->data['User']['password']);
  }
  return TRUE;
}

The above function is called every time a scaffolded action is executed. The password hashing will only be performed if the add or edit actions are POSTed.

After today’s update I won’t be providing further review. I think, for the most part, the decisions I made regarding the server settings have worked out well. There are a few settings that can still be tweaked, but I don’t think any further discussion is necessary at this point. I will, however, make any notes on any extraordinary changes in server performance. I will also report on the effects of any query optimizations.

The thread cache is still at a good level. Current stats say 20 maximum concurrent connections with 18 cached and 100% hit rate.

I think the table cache may actually be at an acceptable level. The number of opened tables is still rising (currently at 870), but not as quickly as it appeared in the last review. It may still be worthwhile to increase the cache slightly, but I’m not as concerned as I was initially.

Temporary tables still appears to be problematic. The percentage of temporary tables written to disk continues to rise (now at around 17.5%). Some of this is likely due to lack of query optimization, meaning a code review needs to be performed. That will have to wait until I have a chance to outline best practices for code development. In the meantime I’m going to raise the values of tmp_table_size/max_heap_table_size from 32M to 48M.

The query cache performance is doing a little better than in the previous update with a 7:1 hit-to-insert ratio. We’re still seeing a large number of prunes (35K) and free blocks (908). Still, these numbers aren’t increasing horribly. This is still likely a problem of leaving out some queries, plus we should set up a cron job to flush the cache on a regular basis in order to keep the number of free blocks low.

The key buffer is fully used, but the key_reads/key_read_requests is still at an acceptable level (.001). It might be prudent to increase the buffer size, but I’ll wait until next review to see how the buffer is holding up.

The read handlers are still alarmingly high. But again, until we spend some time optimizing queries I don’t expect to make any changes to these settings.

Cached threads is still pushing upward (currently at 20 created; 17 cached, 3 in use), but I’m going to leave this at 25 for now. This is something that won’t really hurt us if we go over, so I’ll wait until we get closer to the setting.

Opened tables is still rising, despite a table cache of 256. Right now it’s at 556. I think it may be worthwhile to increase the table cache, but we’ll see how things look at the next review.

The number of temporary tables being written to disk is a little over 10% of the total number of temporary tables. This isn’t as good as the numbers seen in the previous update so it’s worth watching. If the numbers don’t improve the value of tmp_table_size/max_head_table_size should be increased.

The query cache is not performing quite as well as in the previous update. It’s at roughly a 4:1 hit-to-insert ratio (1,652k/427k). Plus, the value in lowmem_prunes is high (19K) and the number of free blocks is also high (368). I’m going to flush the cache and see if the numbers improve. There’s no need to increase the size of the cache, though, since it’s not being fully used. These numbers may have more to do with caching of queries that would best be left out, which is something that can be controlled when issuing a query.

The key buffer still appears to be at an appropriate value. However, the number of blocks used is starting to push against the size of the buffer. This should probably be increased on the next update.

The sort buffer appears to be acceptable.

The read handlers are still fairly high, but queries have not yet been optimized so this is something that may see improvement without further changes to the server settings.