2

Currently I'm checking some client and server software and I wish to expand the testing coverage for it. Specifically I want to increase the quality of the load and stress testing that is performed so that it better reflects user usage.

To this end I've been looking at JMeter, however I've encountered an issue. Unlike a web browser, the client does not have support for using a proxy. This presents the problem that JMeter can't monitor the communication between the two systems to build up the test data.

Possibly JMeter provides for this very scenario, however it's not been obvious in the documentation that there is any facility for this. Although I have some ideas on how to approach this I can't be the first to have encountered this issue, so I'm putting the question out there: how best would you solve this issue?

Paul McCabe
  • 131
  • 6
  • Have you seen this: http://jakarta.apache.org/jmeter/usermanual/jmeter_proxy_step_by_step.pdf? For load testing, JMeter usually takes the place of your client. In the past I've had to write the steps in the test manually. – Berin Loritsch Apr 06 '11 at 16:37
  • Yes thanks, I've read that and then some. To clarify, I'm aware that JMeter acts as a client; however JMeter has the ability to record the data transferred between client and server during a session, and then create tests based on what the client sent (albeit with some manual work). I could create / add to this data manually, but if I can record the data then it'll save hours of work. But if I must... BTW, this is exactly how JMeter would act when using a web browser. – Paul McCabe Apr 06 '11 at 19:17
  • Have you considered using Selenium to record/playback the interactions? If so, you can use BrowserMob http://browsermob.com/performance-testing to perform the load testing. Here's someone who actually used the combo: http://www.eviltester.com/index.php/2010/03/04/selenium-as-a-performance-and-load-test-tool-with-browsermob/ – Berin Loritsch Apr 06 '11 at 19:35
  • It's an idea. It's used elsewhere for testing interaction on a different interface, but it would suffer the same problems (arguably more) in that the limitation isn't in the tools themselves, but with the lack of proxy setting ability in the client. The crux of the problem is that the requests from the client terminate at the test tool (assuming it is the server rather than just a proxy). – Paul McCabe Apr 06 '11 at 20:04
  • Ok, are you saying that there is a proxy server in between your JMeter instance and the server under test? Or are you saying you want JMeter to _be_ the proxy? The reason that I suggested Selenium is that they have the Firefox plugin that extends the browser to generate the scripts for you. That's assuming you want the second behavior. In the first option, you are looking at something like this: http://www.testingminded.com/2010/04/running-jmeter-tests-from-behind-proxy.html. Maybe the choice of words is what's causing my confusion... – Berin Loritsch Apr 06 '11 at 20:28
  • I'm fairly familiar with Selenium so am aware of the browser plugins, remote control, etc. Regarding the test setup with JMeter: JMeter would be the proxy, the client and server communication through it recording the session. The client is not a web browser, it's an application, but with no ability to set JMeter as the proxy. My thoughts are that I need JMeter to forward the client data onwards to the server (i.e. setting the server address within JMeter if possible) or introducing a fourth application that can modify the client packets. Or perhaps there's another method I've not thought of. – Paul McCabe Apr 06 '11 at 20:51

1 Answers1

1

I discovered two methods that answer my own question; one of which is generic, the other specific to Java applications.

As the client that I was working with is written in Java, it is possible to set proxy details on the command line:

-Dhttp.proxyHost=proxyhostURL
-Dhttp.proxyPort=proxyPortNumber
-Dhttp.proxyUser=someUserName
-Dhttp.proxyPassword=somePassword

The Java VM automatically added proxy information to all network traffic from the client, allowing communications to be sent through JMeter and the session to be recorded and replayed back later. (rather than the client communication terminating at JMeter itself as was the original problem)

The second method was to create a small application that intercepted the client network traffic and inject the proxy information into the requests before it reached JMeter.

Both of the above methods worked.

Paul McCabe
  • 131
  • 6