The 'Optimal' SSL Cipher that you configure on your webserver would depend on your customer requirements. In many cases, that would be a factor in the choice of the protocol and cipher suites. Not sure if that is the case for you.
You could configure the best security possible -- only support TLS 1.2 protocol, only ciphers with Perfect Forward Security (PFS) and only AES 256. Within PFS, you may support only the elliptic curve variant ECDHE. You may choose the newer secure GCM ciphers that provide authenticated-encryption and provide very good performance (with AES-NI instruction). But if your most important customer uses IE8 on Windows 7 and you cannot convince them to upgrade the browser, then they won't be able use your service and you will lose a customer.
ssllabs.com provides a web service to scan your site and give ratings like A+, A, B etc. The rating is based on numerical scores (max 100) received for 4 parameters --- Certificate, Protocol Support, Key Exchange and cipher strength. They give higher marks if Perfect Forward Secrecy (PFS), Strict Transport Security (HSTS), to name a few, are supported.
Note that the score may change over a period of time as browsers and servers get patched, new weaknesses emerge, new exploits are discovered etc. Earlier, ssllabs gave a lower rating to sites that did not implement server-side mitigations for the BEAST attack, but they have stopped doing that as they consider it mitigated on the client side (except for the laggard Apple), but more so because the mitigation involved enforcing RC4 (for protocols TLS 1.0 or lower) and it turns out that RC4 is much weaker than previously thought.
You can go to the ssl labs site, enter your url and get the score.
The SSL labs report includes a section on Handshake simulation where it shows a bunch of clients (browsers, Java, openssl) and what protocols, cipher suites, key sizes will be negotiated with your server. If negotiation is not possible it will show "Protocol or cipher suite mismatch" in red. You can lookup the Handshake simulation for the configuration used by your important customers. For e.g., you may see the entry
IE 8-10/Win7, TLS 1.0, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, FS 256
But say you tighten your server's ssl configuration to support only TLS 1.2, then this row will read
IE 8-10/Win7, Protocol or cipher suite mismatch, Fail
But, as your customers migrate/update/upgrade, you can tighten the security with the goal of TLS 1.2 only, PFS only and 256 bits only
Another important info the report provides is whether the cipher suites are in server-preferred order or not. In the former case, the order of ciphers listed in the server configuration will be honored --- so you put the preferred cipher suites first. The first cipher in the list that both server and client can use will be chosen. If you use Apache, you can enable this with the directive "SSLHonorCipherOrder on". For nginx, the directive is "ssl_prefer_server_ciphers on;"