jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Bowesman <Antony.Bowes...@williamhill.com.au>
Subject RE: Why are HttpArguments always encoded?
Date Thu, 05 Jan 2017 22:21:30 GMT
Wyatt,

> > However, this gets encoded, so I debugged the code and found that ALL
> > arguments created via HttpSamplerBase end up calling
> > setAlwaysEncoded(true), so the JSON body gets encoded when it's POSTed
> > and there's no nice way to prevent this.
> 
> That sounded really strange, but sure enough--  every constructor ultimately
> lowers to the one at line 131 of HTTPArgument.java!
> 
> I'd call it a bug.  Generously, a misfeature.  Evidently, it's even been a
> problem in the past, considering this definition at line 620 of
> HTTPSamplerBase.java:
> 
> public void addNonEncodedArgument(String name, String value, String
> metadata)
> 
> So in your specific case, I think you can work around it without any extra code
> by just calling
> 
> sampler.addNonEncodedArgument("", body, "");

Ah yes, that I didn't see! I missed it as it has no Javadoc comments. That will work.

> 
> > Is this a built in limitation for some reason? It seems a rather
> > clunky solution.
> 
> You'll find a lot of weird decisions like this as you start digging into the guts of
> JMeter.  Honestly?  From what I've seen, it's generally safe to assume you're
> hitting some form of legacy cruft that's lain dormant for ages because (for
> the most part ) the JMeter internal APIs were never intended for external
> consumers like you and I.  I know I would like this to change, and I think
> there's even some buy-in from the project leadership, but...
> well, that's the future not the present.

I didn't realise JMeter has been around since 1998, so I am not surprised there's legacy stuff
around. Often the decisions are lost in time, but as you say, it's good to have the full git
history.

> > I have a major performance test framework I am porting to Jmeter and I
> > am implementing it using Java samplers with nested Http samplers, as
> > it's the simplest way to get this across in a short period of time.
> 
> Sounds interesting.  Will you be able to talk about it publicly?

We have been using a tool called eggPlant Performance http://www.testplant.com/eggplant/testing-tools/eggplant-performance/

Like any tool it has its pros/cons, but it's very flexible and works reliably with a distribution
mechanism to manage tests across many load injectors. We have been running 60k virtual users
making 8k transactions/sec covering most of the business logic for the entire public facing
web sites. 

I have developed a simple framework that provides real-time reporting of the test through
logs pushed into Splunk as well as simple externally defined configuration that allows the
test to be tweaked through some simple external config definitions.  

The reason for the JMeter move is the cost of eggPlant. We initially looked at Gatling, but
that would have required a major rethink about how to do stuff, as it does not offer the same
level of dynamic runtime changes that we currently support. JMeter on the other hand just
allows you to make all the decisions at runtime and the sampler model of 

setupTest()
runTest()

Mirrors directly the eggPlant model of pre() and script(), so it's more of a lift-and-shift
approach to the code rather than a conceptual redesign.

After wandering around the code in the debugger, it does look like some of the JMeter classes
were never intended for public consumption, as there are some seemingly odd approaches. Some
of those are:

- the use of a List to store headers in the HeaderManager, so when making multiple requests
through the HttpSamplerBase, if you need to add a header for one request but remove it for
the next, the removal via (removeHeaderNamed) has to iterate a list, rather than just removing
from, say, a LinkedHashMap.

- The seeming inability to get the Test Plan name from the root of the test tree from within
the sampler or to find the CookieManager instance configured at the top of the tree.

- The rather bizarre method 'String getResponseHeaders()' in the HttpSampleResult. Why would
you want to get all the headers as a String rather than get a map of the headers. Under the
covers it takes the map of headers and joins them together as a String separated with line
feeds.

Still, I like the ease of development and ability to debug through the Apache sources, so
whatever needs to be done can of course be done :)

Cheers
Antony

Mime
View raw message