If you’ve been involved with enterprise software development for any length of time, you’ve likely experienced the “performance issues in production” – the application that performs well in development and testing, then is sluggish and unresponsive when migrated to a production environment. The first instinct of many software developers is to start digging into code optimization or application architecture without considering the impact that external systems may have on application performance.
In this post, I’d like to demonstrate a potential performance issue with ADF applications that are secured by ADF Security: network traffic generated between the application and a directory server, and the impacts that poor network or query performance to the directory server can have on our ADF applications.
The Demonstration
To set up a demonstration, I’ve created a simple architecture on a virtual machine that contains all parts of our demonstration ‘network’.
In particular, this demonstration network has:
An installation of OpenLDAP that will be the store for user and group information. On Oracle Linux, OpenLDAP can be installed from the Oracle Public Yum Repository.
A WebLogic Application server configured with an OpenLDAP provider in the default security realm.
An ADF Application that is secured with ADF Security.
There are two groups used by this application: “managers” and “associates”, each of which map to application roles within the ADF application. The application itself is rather simple – it only consists of a login page plus an index page that shows a single panel box depending on your application role. The application will, however, demonstrate the network traffic generated by a single authentication request.
LDAP Traffic Generated By Authentication
Let’s take a look at the network traffic generated by our simple login request. We’ll use a tool called [WireShark][] for measuring network traffic – if you are using Oracle Linux, WireShark can be installed from the Oracle Public Yum Repository. In this first example, we’ll disable the caching features of WebLogic – later on we’ll look at how WebLogic tuning can effect LDAP network traffic.
First, we’ll set a filter to display only LDAP packets.
With the ADF Application running, we’ll log in with a username and password (being watched carefully by the “Security Cow”.)
When we authenticate as a ‘manager’, the application redirects to an index page.
If we take a look at the output of our WireShark sniffer, we can note that this request generated 34 packets over the network.
Subsequent logins by the user generate a consistent 34 packets per login – as we expect as the application retrieves all data from the OpenLDAP server for every login.
If you extrapolate how such a system would need to scale with more concurrent users, you can see that the latency of LDAP Queries made for authentication and authorization will have an impact on the performance of secure ADF applications. Let’s take a look at important tuning feature of WebLogic that will help reduce that traffic – WebLogic’s LDAP caching features.
Network Traffic With WebLogic LDAP Caching
To demonstrate the impact that LDAP Caching can have, let’s re-enable WebLogic caching (both user and group information) with the default caching options that are enabled on WebLogic install. For example, the User caching settings look like this on initial WebLogic installation:
These cache sizes can be adjusted as can the “Time To Live” (TTL) for the cache – both of them parameters that you’ll want to tune for your particular environment.
If we perform the same login action as above, an initial authentication request will be identical to the requests performed above – with 34 network packets being sent to the OpenLDAP server:
Once this initial request is cached, however, subsequent authentication requests produce far less network traffic. In this specific example, the next login request produces 5 packets to the OpenLDAP server (for cache validation):
Once the “Time To Live” (TTL) between login requests for this user has expired however, the cache will refresh itself with the same amount of packets sent as the original login request.
Recommendations: Improving LDAP Performance
Following the results of this demonstration, there are two recommendations that can be made that will improve the performance of secure ADF applications:
Improve Your Directory Server and Network Performance: An obvious starting point would be improving both the performance of the network between WebLogic server and your directory server. A secondary (and more difficult) point of improvement is ensuring that LDAP queries performed against your directory server are both quick and efficient. (A rule of thumb mentioned by one of the Oracle “A-Team” members during a WebCenter performance discussion is that a query should have a mean execution time of under 50 milliseconds.)
I’ve noted that directory server performance is often a secondary consideration during architectural planning – a company will size hardware for concurrent users of an application, set up clustered deployments, etc. – then set up WebLogic to use the common ‘enterprise wide’ directory server to provide authentication. The performance of that directory server architecture must be as critical as the performance of the application environment, as the appellation will only perform as well as the slowest component in the system architecture.
Consult the documentation for your directory server for tips on performance tuning, or perhaps consider using architectural solutions for creating a highly performant directory architecture to service transactional applications.
Tune WebLogic Caching To Reduce Network/Query Traffic: After LDAP and network performance is ‘sufficient’, WebLogic can be tuned to improve performance through caching. Note that the two important parameters are cache size and cache time-to-life; make sure that you’ve taken into account hardware (RAM) for memory used by LDAP caches.
A very good resource for understanding WebLogic authentication provider tuning in general can be found on the “Fusion Security Blog” here.
Here’s a brief video walking through the demonstration: