What SSL key should I make for IIS: RSA or DH? What bit length is appropriate?
RSA and Diffie-Hellman (DH) are just two different algorithms which accomplish a similar goal. For most purposes, there is no overwhelming reason to prefer one algorithm over another (RSA vs Diffie-Hellman). They do have somewhat different performance characteristics. RSA is the standard choice, and it's a fine choice.
It's hard to give a one-size-fit-all recommendation on key size, because this is likely to be dependent upon your site's security needs, and because the key size affects performance. My default recommendation would be to use a 1536-bit RSA key. 1024-bit RSA keys should be an absolute bare minimum; however, 1024-bit RSA keys are on the edge of what might become crackable in the near term and are generally not recommended for modern use, so if at all possible, I would recommend 1536- or 2048-bit RSA keys.
Note that many CAs have recently started deprecating 1024-bit end-entity certificates, as of December 31, 2010: they may issue you a cert for a 1024-bit RSA key, for legacy purposes, if you ask, but they are encouraging people to transition to 2048-bit RSA. Some CAs are requiring 2048-bit keys, no exceptions. Personally, I think 2048-bit RSA is overkill for most purposes and 1536-bit RSA is probably fine, but 2048-bit RSA is accumulating some inertia.
The larger the key, the slower initial connection establishment will be. The most likely impact is on your server's load, since the server has to do a few public-key operations for each new device that connects to it (within a 24-hour period or so). The public-key cryptography only incurs a one-time cost, which is paid once when a connection is created (and not paid again for any new connection within about 24 hours or so); the amount of data transferred over the connection is not relevant.
So, my default suggestion would be: select a 1536-bit RSA key, then test on a typical-low end client (e.g., an iPhone) to make sure performance is OK, then test whether your server can handle the number of connections per day associated with that key size. If you have performance problems on the server, consider a crypto accelerator to speed up your server's performance. If you still have serious performance issues, you could consider dropping down to 1024-bit RSA. If you have a security-critical site, like a banking site, use 2048-bit RSA.
DH and RSA are different public key algorithms, but there is no appreciable difference in security given equal public key sizes. DH certificates are fairly uncommon, and you don't need to worry about them.
The time needed to perform an RSA operation increases approximately as the cube of the modulus size, i.e. a 2048-bit key is about 8 times slower than a 1024-bit key. This mostly affects the server's performance in SSL, because RSA public operations (decrypt, sign) are much faster than private operations (encrypt, verify) and the client only needs to perform a public RSA encryption using the server's public key in most ciphersuites.
In your first case, performance would be strongly affected by the use of SSL session resumption. If a client reconnects to the same server using SSL, it has the option of "resuming" a previous session, which allows it to skip the expensive RSA key exchange. In the second case, long-duration transfers are not affected at all by the server's key size, since application data in SSL is encrypted with a symmetric cipher, not the server's RSA key. For the third case, see (2) above.