You can tune Liberty to maximize the performance for secure applications.
About this task
When you are securing your WebSphere® application
environment, it is important to understand the impact security can have on performance. Within an
application server environment, running applications with security settings can often decrease
performance because of increased processor usage from security tasks such as encryption,
authentication, and authorization. These services can often increase the path length of application
server requests, requiring more resources for each request and slowing down application throughput.
In most cases, you can reduce or eliminate some of this security-related performance loss through
performance tuning. You can adjust the resources that are used by security services and choose to
use only the security services that are required by a particular application or environment.
Achieving the best possible performance, without sacrificing any necessary security, requires an
understanding of your network topology and the security needs of your applications.
- Choose the connections that you want to encrypt.
In a WebSphere Application Server environment, you
can encrypt the following transports:
- HTTP traffic that is to the web server
- HTTP traffic that is from the web server to the application server
- SOAP/JMX traffic
- File transfer service
- Web services over HTTP
When you are determining which traffic to transport over encrypted connections, consider whether
the network that is connecting the communicating machines is private or public. There is a
significant amount of resources that are associated with setting up a secured connection and
encrypting and decrypting the traffic over that connection. You can make significant performance
improvements by not requiring encryption over a secured network, for instance. If your application
does not require that traffic is encrypted from the client to the HTTP server and from the HTTP
server to the application Server, you might be able to use SSL only from the client to the HTTP
server and therefore reduce resources that are required by security.
- Enable on-chip Advanced Encryption Standard (AES) Encryption.
If you are using IBM® SDK Java™ Technology Edition Version
7, Service Refresh 3 or later, and you are running on an Intel processor that supports the Advanced Encryption Standard (AES) New Instructions (AES-NI)
instruction set, you can achieve performance improvement by taking advantage of on-chip AES
encryption. Using these features, you can run AES encryption and decryption using hardware
instructions without extra software.
To enable AES-NI usage, add the following property to the JVM command line or
jvm.options file:
com.ibm.crypto.provider.doAESInHardware=true
Add the following property to the JVM command line or the jvm.options file
to verify that the processor supports AES-NI instruction set:
com.ibm.crypto.provider.AESNITrace=true
For more information, see Intel Advanced Encryption
Standard New Instructions.
- Choose your cipher key length.
In some cases, the bit length of a cipher key is governed by regulations that are put on the
transfer of certain types of data. In these cases, the cipher and key length that you choose for a
particular SSL connection can be predetermined. For situations where the key length is not
regulated, you must choose the appropriate resources to allocate to security so that performance is
not decreased more than is necessary. For example, a 256-bit cipher offers stronger encryption than
a corresponding 128-bit cipher. However, decrypting messages with a stronger cipher requires more
processing time.
When you are making your decision about the encryption strength to choose, consider the type of
data that is traveling across a network. For example, sensitive information, such as financial or
medical records, needs the maximum amount of security. Also, consider who has access to the network.
If the network is protected by a firewall, consider decreasing the strength of the cipher, or
possibly transmitting the data over an decrypted connection.
For more information about configuring SSL settings on Liberty, see SSL configuration attributes
- Set connection keep-alive requests.
In the Secure Socket Layer (SSL) protocol, the initial handshake uses a public-key cipher to
exchange a private key for a faster private-key cipher. This faster cipher is used to encrypt and
decrypt communication beyond the initial handshake. Because the cipher used for subsequent
communication is faster than the one used for the initial handshake, it is important from a
performance perspective to limit the number of SSL handshakes that are performed within the
application server. You can achieve this result by increasing the length of an SSL connection by
increasing session affinity.
One way to increase the duration of a single SSL connection is to enable persistent HTTP
keep-alive connections. Increasing the duration prevents SSL handshakes from taking place on
consecutive requests. You can make sure that persistent connections are enabled by verifying that
the keepAliveEnabled attribute in the httpOptions element is set to true in the
server.xml file. The default value is true.
Another way to tune persistent connections is by setting the maximum number of consecutive
requests on a single HTTP connection. If your clients are making more than 100 requests
consecutively, consider increasing the value of the maxKeepAliveRequests attribute in the
httpOptions element in the server.xml file. The default value is 100.
For more information, see **** MISSING FILE ****.
- Set the authentication cache settings.
Because the creation of an authentication subject can increase processor usage, Liberty provides
an authentication cache to store a subject after the authentication of a user is successful. To
fully take advantage of this service to increase performance, you must make sure that it is turned
on and tuned according to your users and applications.
Make sure that you do not disable the authentication cache. By default, the authentication cache
is enabled to help improve performance.
Consider changing the authentication cache timeout value. Increasing the timeout value enables
subjects to remain in the authentication cache longer and reduces the number of reauthentications
needed. However, increasing the timeout value increases the risk of user permissions becoming stale
compared to a modified external repository, such as LDAP. Set your authentication cache timeout to
reflect the estimated length of client sessions. You can specify the cache timeout by setting the
value of the timeout attribute to whichever time you choose in the authCache element in the
server.xml file. The default value is 600 seconds.
Finally, if you are experiencing authentication times longer than expected, or you are noticing
more traffic to an external authentication repository than expected, the authentication cache might
be full. When the authentication cache is full, subjects are evicted. There is not a one-to-one
mapping of authenticated users to authentication cache entries. The number of entries in the cache
per user depends on other security configurations. It is a best practice for the maximum size of the
authentication cache to be larger than the number of distinct authenticated users that are accessing
the server at one time. Setting the maximum size of the authentication cache this way helps prevent
subjects from being evicted from the cache before timing out. You can change the maximum size of the
authentication cache by setting the value of the maxSize attribute in the authCache element in the
server.xml file. The default size is 25000.
For more information, see Configuring the authentication cache in Liberty.
- Configure the HTTP session affinity settings.
One of the operations in a secure application environment that drains performance the most is the
initial setup, including the SSL handshake and authentication. In clustered environments, performance decreases might occur when a web client
accesses different application servers. To prevent the increased processor usage of the SSL
handshake and reauthentication, it is important to make sure that HTTP session affinity is
configured.
HTTP session affinity ensures that consecutive client requests are routed to the same application
server. HTTP session affinity aids performance in various ways, but specifically, it prevents the
increased processor usage of reauthentication and SSL handshaking. Consult the documentation of your
HTTP Server or Load Balancer for instructions on setting up HTTP session affinity.
For more information, see Configuring session persistence for Liberty.