Figure 2. Test environment physical architecture
Published on dev2dev (http://dev2dev.bea.com/)
http://dev2dev.bea.com/pub/a/2008/03/measuring-aqualogic-security-performance.html
See this if you're having trouble printing code examples
by William Dettelback
03/12/2008
An increasingly common scenario among BEA WebLogic Portal (WLP) customers is the use of BEA AquaLogic Enterprise Security (ALES) for personalization and fine-grained entitlements. One concern with substituting WebLogic Portal's built-in entitlements engine with AquaLogic Enterprise Security is performance. This article examines the effect on the performance of a WebLogic Portal application when AquaLogic Enterprise Security is applied to handle Visitor Entitlements.
WebLogic Portal (WLP) provides a very good solution for managing and enforcing Visitor Entitlements. Visitor Entitlements dictate how the portal is rendered according to each visitor's identity and role assignments. These entitlements are managed as individual rules separate from the actual portal definition. This makes it simple to modify the entitlements as conditions change and new requirements arise. However, WebLogic Portal's built-in entitlements engine works only within the portal domain itself. When entitlements in general are required by other parts of the architecture, WebLogic Portal's implementation cannot be used.
For example, it may be necessary to apply entitlements to specific service endpoints, or selectively apply data redaction to database columns based on a user's identity. To satisfy this need, we need to turn to AquaLogic Enterprise Security (ALES). ALES extends the concept of entitlement policies beyond what is possible with WebLogic Portal alone. ALES can dictate how a WebLogic Portal Desktop should be rendered, and it can determine what should be shown inside a specific portlet (for example, a JSP or PageFlow portlet). ALES provides this ability through centralized management while preserving the ability to enforce these policies locally at the applications themselves. The centralized management is handled by the ALES Administration Server, and each application endpoint is provided with policy decisions via a Security Service Module (SSM). ALES ships with different flavors of SSMs depending on the runtime desired—for WebLogic Portal, we use the WLS-SSM.
So, how do WebLogic Portal and ALES integrate? At a conceptual level, when a WebLogic Portal application receives a request to view a desktop, WebLogic Portal starts to render the tree of portal resources and uses the Personalization framework to determine whether or not this visitor is allowed to see the resources in the tree. Beneath the Personalization framework is the WebLogic Security Framework, which has providers for Authorization and Role Mapping. By default, WebLogic Portal uses its own providers to do Authorization and Role Mapping; this is configured in the Portal Administration Console.
However, when the WebLogic Portal domain is configured to use the WLS-SSM, we are using the ALES Authorization and Role Mapping providers instead. From the portal application's point of view nothing has changed: All personalization requests are still satisfied by the Personalization framework. However, underneath this framework it is actually the ALES, not WebLogic Portal providers at work. For a single portal desktop request there may be hundreds of calls down to the providers—each one requiring a decision whether or not an object should be rendered. For large-scale portal environments, this can translate to thousands of entitlement decisions every second. It is critical that the latency introduced by ALES is as small as possible.
To help keep this latency small, ALES was designed so that entitlement calls from WebLogic Portal would happen entirely within the same process space. This allows ALES to provide significantly shorter latencies than an out-of-process call to a centralized decision point. Because ALES is configured at the WebLogic domain level, all servers in a single domain can take advantage of ALES in a uniform manner. Each server instance in the domain has in-memory access to the same entitlement policies, eliminating the need for a single centralized decision point for the architecture.
Even with an in-memory entitlement engine, it is important to understand the impact on performance; therefore, the ALES team took the opportunity to run some benchmarks. We chose a simple portal application that was typical of a customer's enterprise Web application. We tried to pick a scenario that was small enough to measure effectively while providing enough complexity to get meaningful results.
We set out to determine two things:
The testing architecture is shown in Figure 2. ALES Administration Server (PAP) provided policies to two Policy Decision Points (PDPs)—the first being the embedded SSM inside the WLP domain, and the other being a standalone instance of the Web Service SSM (WS-SSM). The WebLogic Portal server ran the test portal application and delegated all portal rendering entitlement decisions to the embedded SSM. The Web Service SSM was used only to authorize the action, resulting in a button push inside a particular portlet. The WebLogic Portal domain was also configured to authenticate users against the shared user store managed by the ALES Administration Server's database instance.
Figure 2. Test environment physical architecture
LoadRunner was used to simulate the user population, and two physical instances were set up, each communicating to the WebLogic Portal server via HTTP.
The testing application is a fictional financial portal where users perform research, monitor trade blotters, and perform trade transactions. It was intended to serve a wide range of users and therefore required fairly complex entitlement rules across a large population of portal artifacts. The test application was composed of the following structure:
One of the portlets also made an out-of-process call to the Web Service SSM to simulate a "Buy" event. The user population was set up as follows:
The ALES policies were established as follows:
The test case follows a simple scenario of a user working with the portal:
The test case was run in two scenarios: once with ALES enabled for entitlements and once with no entitlements enabled. The number of virtual users was gradually increased from 10 to 70 in increments of 10 every ten minutes. Page response time was measured for each interaction. Each page visit was equivalent to approximately 100 authorization decisions. This broke down as follows:
Notice that we have separate authorization decisions being made for multiple types of Portlet actions ("view," "delete," "minimize," and "maximize"). We have one more authorization happening with each page render. Pressing the "Buy" button made a remote call to the Web Service SSM (WS-SSM) to determine if the user could purchase the security. Note that remote calls to the WS-SSM are broken into two phases; the first is to establish the user context and the second phase is to actually perform the three authorizations. Splitting out the user context into its own call means that we don't have to resend user information (such as attributes) along with each authorization call.
The Load Runner graph in Figure 3 shows the overall number of Virtual Users (VUsers) compared to the number of Load Runner "Transactions" as a function of time. As you can see in the graph, the portal application becomes saturated at about 35 VUsers; this is the point at which the transactions per second are no longer climbing.
Figure 3: Load Runner tests showing virtual users compared to transactions as a function of time
The response times also correspond to this saturation point; we can see that after about 30 VUsers, the average latency per page starts to climb quickly:
| Login Page (ms) | General Page (ms) | Trade Auth Page (ms) | |||||||
| # VUsers | No ALES |
With ALES |
Change | No ALES |
With ALES |
Change | No ALES |
With ALES |
Change |
| 10 | 70 | 100 | 30 | 120 | 140 | 20 | 103 | 135 | 33 |
| 20 | 125 | 160 | 35 | 220 | 240 | 20 | 220 | 245 | 25 |
| 30 | 145 | 236 | 91 | 265 | 360 | 95 | 265 | 358 | 93 |
| 40 | 160 | 300 | 140 | 300 | 420 | 120 | 305 | 395 | 90 |
| 50 | 190 | 372 | 182 | 340 | 520 | 180 | 350 | 500 | 150 |
| 60 | 210 | 510 | 300 | 370 | 720 | 350 | 378 | 700 | 323 |
| 70 | 260 | 580 | 320 | 420 | 800 | 380 | 405 | 790 | 385 |
Comparing the page response times for WebLogic Portal pages with and without ALES, it can be deduced that we have added between 20 to 90 milliseconds of additional latency for the 100 authorization calls per page (or approximately 0.2 to 0.9 ms per authorization call). The timings beyond 30 VUsers are less meaningful since they are mostly measuring the server's inability to keep up with the increasing load.
Each Load Runner "transaction" equated to nine pages. With saturation at slightly over 4 transactions per second we can surmise that we are handling about 38 pages per second. At 100 authorizations per second this gives us a rate of about 3800 authorizations per second at saturation.
What can we conclude from this study? Because the WLS-SSM operates in the same process space as the portal application, the incremental overhead of so many authorizations means milliseconds of additional latency. We did not have specific saturation data for the Non-ALES use cases, so it isn't clear what the precise overhead of doing entitlements would be compared to simply returning back more HTML markup with each page. What is clear is that keeping 99 percent of the authorization requests in-process meant that, prior to server saturation, ALES was not substantially contributing to the overall portal response time. Even the single out-of-process call to the WS-SSM added only a few tens of milliseconds per page.
Of course, these numbers should be taken only as a suggestion of actual performance. Each application's response times and throughput maximums depend on many factors, notably the actual entitlement policies themselves. But it is instructive to examine even a simple use case such as this to understand how fine-grained entitlements can affect overall user response time and system throughput.
William Dettelback currently works on the AquaLogic Enterprise Security team. His focus is on customers implementing SOA Security, particularly Authorization and Entitlement solutions.