I have used the CA Identity Manager command line tools to build test scripts and performance testing tools. These were fine for initial testing but they have their limitation. Better performance tools and/or testing tools are available, e.g. HP LoadRunner.
However, I was looking for an Open Source Tool that customers and CA project resources would be able to leverage, that would have a low-learning curve; e.g. hours versus days/weeks; low cost; and if possible, avoid any installation, e.g. extract and run.
I have evaluated Apache Jmeter, and have found it to a perfect fit. It can manage the two (2) major management protocols of the CA IM solution, e.g. HTTP(S) & LDAP(S). There are many additional features & functions that are possible.
I have a list of performance enhancements to the CA IM solution, but it is always a challenges to capture a "metric" of a before and after state, without diving deep into the logs of the solution. This is not required with the use of Jmeter.
I have created two (2) test plans:
1) LDAP(S) Version for CA Identity Manager' Provisioning Server, to validate load balancing & no issues to scale to endpoints
The LDAP(S) Version was created manually, using knowledge of LDAP, the IMPS service, and use of LDAP client tools.
The primary functionality of the LDAP(S) test plan, is around query operations, to determine if there are any issue with peak usage; especially around hourly E&C operations.
This test plan will also help identify if a CX connector was properly built; and needs to be adjusted for performance.
The test plan may be adjusted to include updates as well.
It has reference how to leverage the IMPS service to use the existing IAMCS(jcs)/CCS connectors to the Endpoint Accounts, regardless if the Endpoints are Mainframes, Databases, AS/400, Cloud Applications, etc.
2) HTTP(S) Version for CA Identity Manager User Console, to emulate what users' see using a browser.
The HTTP(S) Version was created using the embedded HTTP(S) Recorder option.
This is an AMAZING feature of Jmeter. This feature alone will create 95% of your test plan.
I only had to go through the test plan and rename a few items, update a few fields with variables.
This is a very valuable tool, as it can emulate ANY CA IM function that can be done via a browser.
I built this test plan against a system with CA IM and CA SSO integrated.
I have the test plan perform a BIND, CreateUser, ResetUserPassword, DeleteUser for 100 accounts.
I am enclosing both test plans documentation, the Jmeter test plans (jxm/xml), and support csv files.
I consider these to be version 1.x and will be improving them as time permits with use at customer engagements & internal use.
If you have experience with Jmeter and have a particular feature that you think has value, please share. :-)
•General Education. Jump start knowledge with Apache Jmeter and use of HTTP protocol & test plans
•Performance Testing with Jmeter 2.9 by Bayo Erinle , Packt Publishing Open Source, 2013
•Recommended: This is a quick read with excellent labs to follow along with. Includes PerfMon
•Excellent examples how to setup the Jmeter built-in HTTP(S) Recorder to auto-build a test plan:
•https://jmeter.apache.org/usermanual/jmeter_proxy_step_by_step.pdf [Peter Lin]
•Recommend using the default exclusions to avoid non-useful “bloat” returned from standard HTTP GET operations.
•These returned objects are NOT needed for a test plan; and can be deleted. To view: Leave off default exclusions and view the many objects returned to understand.
•Suggest using FireFox as go-to browser to switch to proxy use for HTTP/HTTPS; however may use any browser from desktop to communicate to the Jmeter HTTP Proxy
•CA Support Site Tech Note #TEC478754: Using Jmeter to test Siteminder performance, 11/28/2012
•Excellent notes on using the HTTP(S) operations; use of select Jmeter functions to manage Siteminder Cookies
•Includes a note that SM Authentication schema must NOT be BASIC, but HTML FORM to allow use of Jmeter with Siteminder Protected Apps.
•Use SM UI (WAMUI or FSSUI) to update the default IM IMS Realm to use HTML FORM. May need to define the HTML FORM first.
•Management of the Identity Manager Built-In Cross Site Request Forgery Token Process [OWASP_CSRFTOKEN]
•http://hxtpoe.github.io/performanceTests/testing-login-using-jmeter.html [CSS/Jquery example]
•https://blazemeter.com/blog/how-load-test-csrf-protected-web-sites [CSS/Jquery, RegEx, & Xpath Examples] by Dmitri Tikhanski
•JMeter How to Run Performance tests - CA IG 1.1 by Ricky Gloden, CA Sr. Architect
•Excellent examples of HTTP Labs and use the Jmeter PerfMon tool to monitor disk I/O, CPU & Network Utilization
•Important Note: Update the default HTTPS protocol from SSLv3 to TLSv1 in the Jmeter properties files to use HTTPS protocol.
Edit: 1/8/16 Added 2nd version of the HTTP(S) test plan without the extra features/option package. This will allow users to load this test plan with just the basic Jmeter binaries.
FYI - Ensure that Java JDK7/8+ is available (to use for the JMETER HTTPS Recorder feature; as it will create it's own Java Keystore on the fly).
If you have many Java version installed, to ensure the correct one is used, update the jmeter.sh/jmeter.bat file accordingly.
SET JAVA_HOME=Path to JDK
Note: JMeter will create it's own keystore with the proxy. It uses the -ext extension. If you have errors messages with regards to keytool creating the keystore, update your JDK to 8.
Edit the path to ensure that Jmeter creates its own proxykeystore.jks file with no issues.
Note: Customer & I were able to install latest x64 of JDK as a non-admin users, without an install on MS Windows using notes from this link.
Edit: 1/19/16 & 1/11/17
Step 1. Download 32 bit version (not 64 bit) JDK 7 (or 8) for MS Windows
Step 2. Use 7zip to extract tools.zip from exe file [tools.zip does NOT exist in the x64 bit release]
Step 3. Use 7zip to extract files from tools.zip
Step 4. Open Command line prompt within new folder
Step 5. Execute the following command: for /r %x in (*.pack) do .\bin\unpack200 -r "%x" "%~dx%~px%~nx.jar"
for /r %x in (*.pack) do .\bin\unpack200 -r "%x" "%~dx%~px%~nx.jar"
Step 6: Validate: java -version
Step 7: Update jmeter.bat (jmeter.sh) to use new jdk version.
One customer reported that JDK 8 was not able to work with one web site, due to the website they were attempting to record, was using a lower version of SSL/TLS protocol than was allowed by JDK 8.
Note: Java 8 implements SSLv3, TLSv1.0, TLSv1.1 and TLSv1.2, but recent updates (8u31 or 7u75 and up) disable SSLv3 by default because of POODLE.
If you are unable to adjust the website, then deploy JDK 7 on your desktop; and update Jmeter .bat/sh accordingly.
If there is an issue with sslProtocolException when accessing a site with TLS/SSL with latest JDK, add the following to the jmeter.bat/jmeter.sh
set ARGS=%DJSSE% %DUMP% %HEAP% %NEW% %SURVIVOR% %TENURING% %PERM% %CLASS_UNLOAD% %DDRAW%
thank you for sharing. I'm not an expert in JMeter, however, i work in a team where JMeter was setup and use extensively, and i hear a lot of good thing about this tool. Will share this post w/ others in my team. i'm sure they will get a kick out of this.
Definitely awesome. I will agree with the approach of Alan. I have used this approach in past and found it very useful where advance testing tools and procedures are unavailable. I also believe we should standardize this approach to have some sort of out of box capability. I am sharing this with others.
Thanks Alan for sharing this. This is extremely helpful.
Thanks for the feedback.
I think this process fits well in to the concept of "Fail Early, Fail Often, Fail Cheaply"
Allow this tool/process to build the test plans, execute the test plans, and help us find the "challenges/surprises" BEFORE we move the solution into the next environment (or Prod).
Let's play "whack-a-mole" early for any issues, rather than later. :-)
This tool is a great tool for verifying functionality in Identity Manager. We can test uses cases related to a particular functionality and in this way quickly verify that nothing has been broken when new functionality has been introduced.