Written by Corbin Links, Identity Access Management (IAM) Engineer
Links Business Group LLC
How to quickly, reliably and easily conduct system load testing for Novell Access Manager 3.x (Hereafter referred to as “NAM”)
Configure and run NAM tests at LoadStorm.com
This article assumes you have a basic familiarity with:
Disclaimer: The author is in no way affiliated with LoadStorm.com, its partners or subsidiaries. Information provided in this article is intended solely for informational and convenience purposes. Information and statements provided in this Cool Solution are those of the author and not The Washington Post Company.
Arguably, one of the most crucial tasks of implementing any form of identity access management (IAM) framework or SSO system is the ability to verify that the system can withstand large amounts of concurrent load. Authentication (authN), Authorization (authZ) and Auditing operations though lightweight and inexpensive from a transaction standpoint, can negatively impact system performance when occurring in large quantities over short periods of time. How much or how little load your NAM system can or should handle will be defined by the requirements of your application and any corresponding Service Level Agreements (SLA) you may have in place.
Unfortunately, load testing is one of the crucial elements of any Authentication Infrastructure that can be often overlooked or short changed during pre and post implementation stages. Here are just a few of the reasons:
Application load testing requirements vary tremendously between application designs, infrastructure environments, business requirements and usage requirements. The following list provides a high-level general set of testing guidelines. This is the list we have used for our NAM deployment and similar deployments in the past. Though far from comprehensive for all environments, the goal is to provide general guidelines to help you get started.
At its most basic level, your NAM load testing will stress the following components:
For the remainder of this document, we will assume the following basic transaction is common to all our NAM-protected testing scenarios:
Here are the steps from browser/UA (User Agent) standpoint:
Before we set up the testing solution, here were the basic requirements that we wanted to test against:
LoadStorm.com is a highly scalable cloud-based load testing service. For additional information about the LoadStorm service of company information, please visit their website at http://www.loadstorm.com.
Once logged into LoadStorm.com, you can start configuring and running test cases. Since this Cool Solution is not intended as a detailed tutorial on all the options and possibilities within LoadStorm.com, we will instead focus on the core elements of creating and running a NAM-centric test case.
If you have not previously used LoadStorm, it is a good idea to experiment and familiarize yourself with one of the existing demo cases, such as the "CIA Factbook" case. Running a demo case will give you a pretty good feel for how the tool operates and how it outputs results. Additionally, the demo cases are designed to be copied to new cases and customized to fit other use environments.
Before building and configuring your first test case in LoadStorm, here are a few points to keep in mind:
These are actually three separate scenarios, rather than steps as described in the annotation red box. Steps are shown once you click on a scenario.
Now, let's set up a more useful test. Here is what we did:
LoadStorm runs scenario test steps dynamically as you build your test. Each preceding step must be run successfully before the next can be executed. If there are any errors such as unreachable URL's or forms that cannot be processed, LoadStorm will provide this information in the script build page. Since our internal LoadStorm NAM tests include URL's and data we don't necessarily want to share in this Cool Solution, let's run the "CIA" test case and see what displays and how it displays.
To Run a LoadStorm Test:
Let's examine a "Response time" graph taken from a live ERP Time Reporting test we ran recently. This test was run against one of the sandbox servers and used the basic NAM login / logout test discussed previously, but with a couple of additional steps.
The dark blue line is showing the "Peak Response Time" which means that it measures the slowest responding transaction during that minute interval. This line highlights your outliers of poor performance. The light blue line is showing the "Average Response Time" and will almost always be much lower than the peak response time because your system will respond quickly to some requests. For example, your login page may be slow due to processing bottlenecks at the database, while a small static image should be much faster since it requires no extra processing for the web server to deliver. Generally, database access is one of the common performance offenders in a load test.
The graph displays a direct correlation between the Average Response Time and the Error Rate. We can see the Peak Response Times hit the 35 second threshold at about the 40 minute mark as our system starts to take longer to respond.
By clicking on the "Show requests by error code" link above, we can look at a couple of URL's that failed a large number of times: Our application login page and the Novel Identity Server redirect page:
At a high level, the graphic tells us that users trying to log in again much later in a test are waiting a very long time to receive login pages (35 seconds or more.) Either the NAM session isn't being correctly torn down, or our NAM sandbox instance is being staggered by load. We will investigate further and re-run the tests after any configuration issues are mitigated.
When analyzing LoadStorm test results (always available on LoadStorm's "Analysis" tab,) it may be tempting to view LoadStorm or any load testing platform as a diagnostic tool. LoadStorm does not directly fulfill this role, though when used correctly can provide extensive information to help diagnose and trouble various NAM and application bottlenecks. In our case, we made a number of policy tweaks and graphic size reductions based on errors we encountered during the load tests. Natively, LoadStorm provides key data such as URL's, response times and HTTP Error Codes (most often related to the 400 series of codes), and the data can be downloaded from LoadStorm.com as a CSV file. However, the data collected from LoadStorm, when used in conjunction with web/application server and Novell Identity Server Logging can help pinpoint key bottlenecks in the system and identify potential throughput problems before you flip the switch to go live in production.
This Cool Solution has just scratched the surface of what is possible with external load testing tools such as LoadStorm. When load testing a NAM environment, be sure to consider estimated and actual peak users, while simulating real-world authentication and authorization patterns. There is no need to throw 5000 concurrent users at a system just because you can, or have a handy tool supports it. Testing 5000 concurrent authentication actions for duration of 45 – 60 minutes can literally push 20,000 or more total transactions through your system within the test duration period. This level of concurrency is a very large number represents uncommon load levels for internally-facing intranet applications. However, if you do need this level of concurrency or higher, LoadStorm can "handle the load" nicely.
For additional information, please visit:
IAM Success Tips: http://www.iamsuccesstips.com