With a modern but not-so-speedy x86 processor, and a good enough implementation, cryptography speed will not be the bottleneck. For instance, consider a quite cheap AMD Athlon 2650e processor, a not-so-modern and really-not-so-speedy processor that I have in my home file server; it is clocked at 1.6 GHz and has a single core. It can still do about 2200 RSA private key operations per second (for a 1024-bit RSA key). I seriously doubt that the Linux kernel on which this machine runs can cope with 2200 new TCP connections per second...
(Note that for anything related to RSA, running an x86 CPU in 64-bit mode is a huge win -- that's what I do with my cheap server, by the way. In 32-bit mode, divide the figure by 3 or 4; this would still be quite respectable performance.)
Also, SSL/TLS has a feature known as "abbreviated handshake" which is about a client connecting again and reusing the asymmetrically exchanged secret of a previous handshake. See section 7.3 of the standard. The abbreviated handshake involves symmetric cryptography only, no RSA. Note that, in practice, the best thing about abbreviated handshake is that it implies less network packets and lower latency; the lower CPU usage is nifty but not so visible when actually measured.
Assuming that you nonetheless find the asymmetric part of SSL to be huge on the CPU budget, your best bet will still be a "plain RSA" cipher suite, although there could be a tie with ECDHE cipher suites (but the only elliptic curve which is decently supported by existing clients is the P-256 curve, which is fine but somewhat an overkill if you just aim at 80-bit security).
SSL/TLS also uses symmetric cryptography, and that one can use some CPU, too. An x86 CPU is more than powerful enough to encrypt all data which can go through a 100 Mbits/s link, but you can have some savings if you choose your algorithms properly. In practical terms, this means: use AES or RC4, not 3DES. AES will be exceptionally fast and cheap if your CPU offers the AES-NI instructions (and if your SSL implementation uses them, of course).
For the hash algorithm, MD5 is somewhat faster than SHA-1, but SHA-1 can already process 240 Mbytes/s (mega-bytes, not megabits) on my cheap AMD CPU.
So this points at
TLS_RSA_WITH_AES_128_CBC_SHA to be the cipher suites of choice for who wants to get the most connections per second for the least CPU. Or possibly
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, which will be less widely supported, but will give you Perfect Forward Secrecy, which can be a nice thing to have.
This being said, performance can depend a lot on architectural details and the exact operation environments, therefore you shall measure. Try it and see if changing the cipher suite makes any actual difference. Remember that performance has often a lot more to do with the amount of efforts invested in the protocol implementation, than with the intrinsic merits of the algorithms themselves.