JMeter JMX example

[J_R_Furman]

I'm looking for JMeter JMX file someone has used successfully to authenticate a SAS Web Application i.e. SASStoredProcess app.

Thanks!

[SimonDawson]

Looking at that tool it just plots JMX metrics? Not sure how helpful that will be. What is the actual problem you are trying to solve?

[JuanS_OCS]

Hello @J_R_Furman,

please have a look to this piece of documentation, I think it will help you

http://support.sas.com/documentation/cdl/en/biwaag/63149/HTML/default/viewer.htm#a003311021.htm

I used JConsole in the past, to get the JMX collected metrics (not JMeter, but basics should be the same).

The point is that you connect to the Web Application Server, not to an specific SAS Web Application, and in the Web Application Server you can see the JVM metrics for each of its hosted Web Applications.

[boemskats]

Hi guys,

JMX is a confusing TLA, as .jmx is also JMeter's file format extension, for load test projects.

@J_R_Furman, I've attached one of our test projects that does what you need. It's configured to test the SAS SPWA, and we normally use it in conjunction when benchmarking / soak testing client environments in conjunction with our own software ESM for SAS. 

When I sent this to one of our clients a couple of years ago I documented it quite well in the email, so I'm including that verbatim below in case it helps you:

I've  been wanting to turn this into a blog post for ages, so I thought I'd use you as a sounding board while I try to work through putting the logic to paper. Hope you don't mind.

So, a few notes on the attached test:

What this test does is (starting from just below the HTTP cookie manager bit of the tree): 

- Makes a call to the SASStoredProcess webapp

- Expects a 302 redirect to SASLogon and follows it

- Parses the SASLogon HTML form for the hidden inputs of 'lt' (login token), 'execution', 'action' and 'eventId' using JMeter's XPath Extractor component and 

- Loads those into JMeter internal variables

- Uses those variables to submit a username and password to the SASLogon webapp

- Carries on with a 'Hello World' loop, and after that's done, a 'Shoe Graphics' loop - just calling SAS's stock STPs as an example 'test' 

- Logs out 

Jmeter lets you define user variables using the User Defined Variables node and then use them in the other nodes downstream, by configuring settings as ${my.user.variable}. I've done this for the test configuration and server configuration bits, so when you want to run your tests on your own servers you can change the values set in the Server Configuration node. I've commented all the parameters in the configuration nodes, so you can have a look and see what each does - think it'll make sense to you.

So - how this would have been useful with your previous sticky sessions issue:

This is an end to end test, which includes the logon to SAS vis SASLogon, subsequent requests to SASStoredProcess looped N times, and then a logoff from SAS. When you run a test, the Results Tree element shows your results, and looks like this:

In this instance, there are 3 virtual users. The little circle next to the SASLogon bits signifies that there was a redirect that you can expand it to to see the requests, which are the 302 redirects to the saslogon app and the 200 from the SASLogon app to load the logon screen. As there are no subsequent redirects, the web tier is functioning properly as the correct auth cookie is being used (there is no load balancer on our dev server, so of course it is).

What you would have seen had you tested your web tier before with this method is every fourth or fifth Hello World request being either redirected back to SASLogon (with the little circle next to it like the SASLogons above), or failing and appearing in red if you were getting 403 errors (different failures mean different things in terms of what's misconfigured - I suspect you'd have been seeing the redirects).

I've left the attached project configured to run a test against our dev server. If you load it up, click this  (clear all results) and then this (run all threads now), you should be able to run a small load test against our devbox. Have a look at the Results Tree component to see the calls being made (you might have to expand the thread group). We're playing with some different configurations & collecting data at the moment, so there might be some unusual MultiBridge session setup on our environment. Nevertheless you'll be able to see the results of the test in real time via https://edge.boemskats.com/esm-1.0/ -> Live View -> The STP multibridge session with the lowest port (as we use the cost-based LB).