I'm doing a lot with update handlers these days. This is where I put almost all of the configuration changes for a release. Putting configuration changes in update handlers has the huge advantage of (a) source controlling these changes, and (b) allowing you to qa them. I strongly recommend this practice.

Most configuration changes are very easy to make in code. Often all you need to do is call variable_set. Sometimes, you have to write some SQL to directly change a table value.

The difficult changes usually involve CCK content types. A year and a half ago I wrote on Programmatically Create, Insert, and Update CCK Nodes. In Drupal 5.x it's not easy. (I hear it's easier in Drupal 6.x, but unfortunately, I have yet to do much 6.x work yet.) I've adopted the practice of doing all configuration changes except for CCK content type changes, in these update handlers... the CCK changes we've managed using the UI.

Up until this release... In the latest release, our client had a board meeting during the sprint, so we had to put all the CCK changes in the update handler too. There were lots of CCK changes, so we had to clear the cache multiple times during the update.

We discovered that clearing the CCK caches in the middle of your update handler uses a lot of memory, and in our case, broke our server limits.

And the tip you've been waiting for...

If you use update handlers, and if you clear the cache, the cache clear should always be the last thing you do. If you need to clear the cache multiple times, you should use multiple update handlers.

And the second tip...

Increase the php limits for just update.php by changing the memory_limit in your .htaccess:

<IfModule mod_php5.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
+  # Increase the memory limit for update.php
+  <FilesMatch "update.php$">
+    php_value memory_limit 512M
+  </FilesMatch>
</IfModule>