What should I know before configuring Perfect Forward Secrecy?

PFS in SSL implies that the server performs, for each new session, a Diffie-Hellman key exchange and a signature, so the CPU cost of the handshake on the server is about doubled compared to a non-PFS cipher suite. But it is rather infrequent that the handshake CPU cost is non-negligible (clients which open several connections use the abbreviated handshake which uses symmetric cryptography only, and a basic PC has enough power to handle several hundreds of complete handshakes per second with a single CPU core). I suggest making an in-context benchmark.

Still with SSL, there is no defined PFS-able cipher suite which also supports RC4 encryption. Apart from that, all non-archaelogic Web browsers currently deployed will accept the "DHE" cipher suites (which yield PFS) so there is no interoperability issue here; the question is rather whether you want RC4 or not: you have to balance the fear of ulterior key compromise (against which PFS adds some protection) with the fear of chosen-ciphertext attacks (i.e. BEAST, to which RC4 cipher suites seem immune).

The OS or load balancer might report cipher suites statistics, but I would not bet on it. You can make tests with OpenSSL (the command-line executable, with the s_client command). You can also use any decent protocol analyzer like Wireshark, which can tell you which cipher suite is used on a given connection (the cipher suite identifier is sent "in the clear" as part of the initial steps of the handshake, so it is easy to grab it with a sniffer).

Interoperability was an issue in the past, particularly in ipsec. SSL is a little easier, but not all clients support it. If I wanted to check my traffic, I'd probably tcpdump on a span port and write a script to look for the accepted cipher suite in the handshake, assuming we're talking SSL.