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
