Let me answer your last question. No, AES-NI will not increase your SSL performance significantly. A CPU which has the AES-NI instructions can encrypt data without using these instructions at a rate of more than 120 MB/s (probably more than 200 MB/s on a server), i.e. more than 10 (or 20) times what 100 MBit/s ethernet can provide. Correspondingly, the best you can hope for, at the best of times and with a supremely efficient hardware implementation of AES, is to save less than 10% (or 5%) on CPU. That's not "significant". Since you use Tomcat to process the data, I seriously doubt that the encryption cost of AES is even detectable on your server. Sure, with AES-NI the processor can encrypt 15 times faster, but since encryption already uses a negligible overall amount of CPU, what would be the point ?
A much quoted data point is what Google said when they switched Gmail to site-wide SSL: they measured a CPU load increase by a meagre +1%. Of course, impact may vary on site type and amount of processing for each request, but we can keep that in mind: SSL is cheap. Making it cheaper will not offer tremendous gains.
Now, for your other questions, the implementation of AES which uses AES-NI instructions should be automatically selected (without needing any configuration on your part) if all of the following are true:
- The CPU supports the AES-NI instructions.
- The actual implementation of AES (as used in SSL) is OpenSSL.
- That version of OpenSSL is 1.0.1 or later.
Thus, if you use Tomcat behind mod_ssl (in Apache) and your local OpenSSL library is recent enough, then you already benefit from AES-NI goodness. If you do the SSL with Tomcat itself (thus relying on Java's internal cryptography), then chances are that you end up with some Java code which does not benefit from AES-NI -- but this would deserve investigation (namely benchmarks). My opinion is that it will make no measurable difference whatsoever anyway, so the point is kinda moot.
