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

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.

The following entry in /etc/subversion/config will configure the files/directories that subversion should ignore:

[miscellany]
global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store _baks* _mm* _notes* *.lck *.LCK *.bak *.BAK dwsync.xml

For comparison, the previous table structure contains 60,864 rows and weighs in at 13.8 MB. Since a row in the old table correlates with all the data for a test item it was significantly more efficient in terms of storage. The new table, in order to accommodate the same number of items and growing at the current rate, would take up 60 times as much space.

After some research I found that that the trouble has to do with the format of the row. The current format is static (fixed) length, but for variable-length data a dynamic row is better suited for space considerations. Most of our tables use the dynamic format. Updating this table to dynamic cuts the size of the table down by a factor of 100.

There are some drawbacks to dynamic rows, however. I’ll be adding some documentation regarding this setting to the upcoming post “Optimizing MySQL Table Structure and Queries.” In the meantime you can find out more information about this setting from the MySQL Reference Manual. See 13.1.3. MyISAM Table Storage Formats.

My assumption of the max number of concurrent connections appears to be fairly close. So far we’ve hit a concurrent connection max of 16. I’m not sure how MySQL determines when to cache a thread, but our thread cache is only at 8. Probably related to thread age, but something that should be researched.

I’m going to lower the maximum connections to 50 (from the default of 100). We’re not coming anywhere near 100 and since the purpose of this setting is to prevent resource depletion it’s better to play safe than sorry. At some point in the future we should calculate the maximum per-connection resource usage and adjust this setting based on that information.

The query cache seems to be performing well with what appears to be a high hit/insert ratio (1,179K/31K). It has plenty of free memory after 11 days of usage and no low memory prunes. It does show some modest fragmentation as indicated by qcache_free_blocks having a value of 47.

The key buffer setting also appears to be acceptable. Our key_reads/key_read_requests is still significantly below the .01 ceiling recommended by MySQL.

For the number of temporary tables created (148K) we’re not looking too bad on the number that had to be written to disk (1,840).

The table cache appears to be doing well, though still not being used fully. Again something that might relate to pruning by MySQL based on age, but I’ll need to research this more as well.

The one number that is disconcerting in the stats is handler_read_rnd_next with a value of 538M. The documentation states that a high value here probably indicates that tables indexes are not optimal for the queries being run. This is also bourne out by the values of select_full_join and select_scan. We should spend some time analyzing our queries to determine where optimizations can be made.

Next update at around one month.