Minimizing Bootstrapping.

does anyone know off the top of their head which phase would be sufficient to execute a Rules invoke event in?

You'll need a full bootstrap. But if you've got enough dev skills to get this far, you might consider not using Rules and just do it in code. I avoid Rules where possible so that I can add documentation about why things are happening.

if I bootstrap to to DATABASE, and then later call bootstrap again for a later phase, will it re-do all the bootstrapping it did for the database phase

Nope. There's a static in there that keeps track of which bootstrap steps are already complete.

Regrettably it is not save to invoke anything calling module_implements() before DRUPAL_BOOTSTRAP_FULL. Doing so may lead to very weird and hard to track errors because you risk to corrupt the module_implements entry in the cache_bootstrap when not all modules are loaded.

You can use bootstrap_invoke_all instead (if you control all of the code which is invoked from there).

It seems like your looking for this setting:

This tells Drupal to pull the entire page out of a cache and skip the database bootstrap altogether obviously you'll want to avoid storing your page cache in the Drupal database for this :-)

For a cache_page miss Drupal will progressively access it's cached resources and invoke hooks to build the page and return as early and as fast as it can. The trick is to make sure everything Drupal needs to build a page is cached as much as possible (lists of modules, hook implementors, etc) which is a fairly long list but most of it is done for you out of the box unless you have less optimized modules hooking into your page build or your own custom code isn't doing it.

Cheers,
Ben

If you look at the bootstrap code, you can generally run all the levels very quickly up to FULL bootstrap. (I'm sure this varies by server and config, but eg just loading a bootstrap level and echoing 'hello world' can easily be done w/in 100ms--that includes network time, etc so from your server to your browser).

The real hitch in the giddyup seems to be line 5127 in includes/common.inc -- the call to module_load_all(). Again depending on your setup, you can expect to pay a 1ms-5ms penalty per enabled module. EG, if you have 120 modules enabled you might see 300-500ms here. (In my initial testing, an opcode cache like APC helps quite a bit here--Pantheon should already have technology like this enabled tho)

The timings here are just for demonstrative purposes--you should definitely confirm on your own environment--however, I think that realtime processing becomes very difficult if you are spending half a second just loading files. If your use-case is small enough, you might be able to include only the files you need--and for ultimate speed directly include the file over drupal_load which will call the db or scan the filesystem. Definitely a running w/ scissors option--caveat emptor :)

Skipping Rules altogether and using some simple logic + meta data/config--like an ini file--might also work.

Cheers