Re: About Raw Post Body name
+1, I'd suggest Message body on a related note, is it only me who thinks it is weird that the parameter view is either url-params or post-body-values depending on what method you select? On 25 August 2013 23:21, Milamber milam...@apache.org wrote: Le 25/08/2013 22:07, Philippe Mouawad a ecrit : Hello, IN HTTP Request, I wonder if Raw Post Body field is still relevant as it can also be used for: - PUT - DELETE - PATCH Should we rename it Raw Body ? Yes +1
Re: About Raw Post Body name
Note: I'll use POST as in every http request that can have a body Jeah, it's essentially https://issues.apache.org/bugzilla/show_bug.cgi?id=55256. The current implementation treats the Parameters and Post Body as kind-of-the-same (as in both is just request data), which means the behaviour is entirely dependent on the verb you select. Eg. if you select POST as a verb, the Parameters get sent in the body like it works for basic html-forms, if you select GET they get sent as url-params. The Post body is just a way to prevent this auto-parsing in case of sending a POST which in turn is the same as having a single unnamed parameter and just putting the post-data in the value field (which is the way that we sent json requests before the post body was introduced ... though I am degressing). So if you want to do a POST-request that has not only a body but also a url-params (which I have come across at times already), you have to write them in the address field by hand instead of having a nice form. On 26 August 2013 21:59, Philippe Mouawad philippe.moua...@gmail.com wrote: Changed it to Body Data. @Immanuel, Not sure I understand your question, could you illustrate with examples ? I saw the bugzilla you opened, is it related ? Thanks On Mon, Aug 26, 2013 at 9:04 AM, Immanuel Hayden immanuel.hay...@gmail.comwrote: +1, I'd suggest Message body on a related note, is it only me who thinks it is weird that the parameter view is either url-params or post-body-values depending on what method you select? On 25 August 2013 23:21, Milamber milam...@apache.org wrote: Le 25/08/2013 22:07, Philippe Mouawad a ecrit : Hello, IN HTTP Request, I wonder if Raw Post Body field is still relevant as it can also be used for: - PUT - DELETE - PATCH Should we rename it Raw Body ? Yes +1 -- Cordialement. Philippe Mouawad.
Re: Refactoring in HTTPHC4Impl
Hi! I got only one request regarding this which is to make sure that the server can still contain part of the address eg server = api.example.com/V2/ address = testservice.svc/health because I use that quite heavily in my testcases, as locally the project runs directly on localhost with no subdirectory and on the servers it runs in the Vx subdirectories - devs and myself just have to change one line and not every sampler if they want to try something. in any case, thx for the great work :) br, Imm On 1 July 2013 17:18, Philippe Mouawad philippe.moua...@gmail.com wrote: Created bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=55175 Waiting for your feedback before commit. On Mon, Jul 1, 2013 at 5:06 PM, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, As per sebb request, I ask before implementing :-) I would like to refactor slightly HTTPHC4Impl to allow inheritance from it to reuse many of already implemented and useful internals. This would be useful to classes that which for example to post binary content and similar stuff. Are you ok with it ? Can I open a bugzilla and do it ? Thanks -- Regards. Philippe. -- Cordialement. Philippe Mouawad.
Re: Refactoring in HTTPHC4Impl
been there, tried that, way less convenient.
had something like this:
server = ${server}
url = ${version}/testservice.svc
which is okay if you have only a handful of samplers or you can copy/paste,
but if you have many different samplers with hugely different endpoints and
assertions / extractors attached like me it is quite tedious to have that
string everywhere (among other reasons because $,{ and } are very annoying
to type on german keyboards).
Or is there some way to set a common prefix in a http request defaults or
similar?
On 2 July 2013 01:13, sebb seb...@gmail.com wrote:
On 1 July 2013 19:06, Immanuel Hayden immanuel.hay...@gmail.com wrote:
Hi!
I got only one request regarding this which is to make sure that the
server can still contain part of the address
eg server = api.example.com/V2/
address = testservice.svc/health
because I use that quite heavily in my testcases, as locally the project
runs directly on localhost with no subdirectory and on the servers it
runs
in the Vx subdirectories - devs and myself just have to change one line
and not every sampler if they want to try something.
I'm not sure we can guarantee that, as this behaviour is likely an
accident of the way the HTTP code is implemented. It's certainly not
documented as being supported by JMeter, and might have to change.
There are other ways to achieve the same effect, e.g. by using a test
plan variable.
in any case, thx for the great work :)
br,
Imm
On 1 July 2013 17:18, Philippe Mouawad philippe.moua...@gmail.com
wrote:
Created bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55175
Waiting for your feedback before commit.
On Mon, Jul 1, 2013 at 5:06 PM, Philippe Mouawad
philippe.moua...@gmail.com
wrote:
Hello,
As per sebb request, I ask before implementing :-)
I would like to refactor slightly HTTPHC4Impl to allow inheritance
from
it
to reuse many of already implemented and useful internals.
This would be useful to classes that which for example to post binary
content and similar stuff.
Are you ok with it ? Can I open a bugzilla and do it ?
Thanks
--
Regards.
Philippe.
--
Cordialement.
Philippe Mouawad.
Re: PERFORMANCE = Changing JMeter defaults to ensure better performances by default
regarding 2: i think it would be better to have some checkbox in the test plan like disable taxing listeners (View Result Tree, ...) like we now have eg. with run thread groups consecutively as you then don't have to change the test plan between development and actually running which may be prone to introducing errors and/or forgetting stuff. On Mon, Dec 24, 2012 at 2:20 PM, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, I am kind of annoyed of reading articles, blogs that say JMeter cannot perform high Load Tests, consumes lot of memory, generates OutOfMemory ... This has become a kind of Urban Legend partly due: - to issues that have been fixed for a while now - and partly In my opinion to some default configuration parameters that lead to these issues In my opinion, we should: 1) change these defaults to avoid new comers, beginners fall into all these traps and others check they are using it well: - Save Service using XML output = Change to CSV - Distributed Mode that uses the Standard which is far from being the best performing Sample Sender = Change to Batch or StrippedBatch 2) Add warnings on GUIs of all elements that are more suited during Scripting than during Load Test : - View Result Tree (I keep seeing people use this element during High Load Test ! ) - View Results in Table - Graph Results - ... 3) Add a popup warning when Start and Remote Start are clicked from GUI to encourage NON GUI mode use (we could add a checkbox Remind Me later which could be unchecked to avoid it again, but at least user would know about it). 4) Finally use some kind of visual indicator (RED background) on some options that have high impact on performance: - Javascript as scripting language - Body (unescaped) in Regular Expression Extractor (*this one is a real performance killer !*) - Encourage JSR223 Samplers + Groovy + Caching instead of Beanshell - ... Maybe we should post this mail on user mailing list to see what users think about it. -- Regards Philippe M.
Re: Substring
+1, iirc I have some code like that myself (the beanshell one ;)) On Mon, Nov 5, 2012 at 9:08 PM, Philippe Mouawad philippe.moua...@gmail.com wrote: Hello, I am working currently on a test where I need substring function. I see it seems to require either javascript or beanshell, wouldn't it be useful to have a jmeter function ? If you are ok, i will implement it and raise a bugzilla. Regards Philippe -- Cordialement. Philippe Mouawad.
Re: SNMP Sampler
GPL is a problem obviously, as it requires that even the project you use it in (no matter how) is GPL-compatible. LGPL does not have this restriction, so as long as we only link against the library and don't include modified sources (which is I think what the linked article refers to), we should be dandy ;) anyhow, if there are Apache-license equivalents it would obviously be better (maybe the authors can be persuaded to do some dual licensing?) On Wed, Aug 22, 2012 at 9:29 AM, Milamber milam...@apache.org wrote: Hello, Sorry, GPL or LGPL products cannot be included in a Apache Licence product http://www.apache.org/legal/resolved.html#category-x Milamber Le 22/08/2012 03:33, Anthony Johnson a ecrit : Hey Guys, My current company developed a SNMP Sampler w/RRD Graph Listener for JMeter and I am working to get permission to contribute this code. I'm a bit worried about licenses as we depend on 3 libraries: SNMP4J - Apache:-) Mibble - GPL JRobin - LGPL Thoughts?!? Thanks, Anthony
Re: SNMP Sampler
PS: mibble up to version 2.3 is actually GPL with linking exception (in their own terms essentially LGPL) ... maybe this helps if there is no suitable alternative. On Wed, Aug 22, 2012 at 10:27 AM, Immanuel Hayden immanuel.hay...@gmail.com wrote: GPL is a problem obviously, as it requires that even the project you use it in (no matter how) is GPL-compatible. LGPL does not have this restriction, so as long as we only link against the library and don't include modified sources (which is I think what the linked article refers to), we should be dandy ;) anyhow, if there are Apache-license equivalents it would obviously be better (maybe the authors can be persuaded to do some dual licensing?) On Wed, Aug 22, 2012 at 9:29 AM, Milamber milam...@apache.org wrote: Hello, Sorry, GPL or LGPL products cannot be included in a Apache Licence product http://www.apache.org/legal/resolved.html#category-x Milamber Le 22/08/2012 03:33, Anthony Johnson a ecrit : Hey Guys, My current company developed a SNMP Sampler w/RRD Graph Listener for JMeter and I am working to get permission to contribute this code. I'm a bit worried about licenses as we depend on 3 libraries: SNMP4J - Apache:-) Mibble - GPL JRobin - LGPL Thoughts?!? Thanks, Anthony
Re: Change the default implementation of HTTP in HTTP request ?
I personally rely on HC4 as it allows me to put more than just the host in the host field (ie. also part of the address) ... why I do this? I mostly test our API which is running on (test.)api.xyz.com/Vx (x = version) whereas our devs partially have it run on their local machines just as localhost (so, without the Vx-subdirectory). Also the version almost never changes (and if it does it usually creates breaking changes which call for refactoring most TCs anyhow), so the part I put in the host line is essentially a static string that would only add overhead in the other fields. Sidenote: personally I don't understand why we have a split host and address field anyhow and not just one line (which then can be split on the first slash or something - there is surely a lib for this - should the http-implementation require so), but that's another story ;) On Tue, Aug 21, 2012 at 6:11 PM, Milamber milam...@apache.org wrote: Hello, Regardless Cookie Manager (HC3/HC4), It's would be a good thing to change the default implementation of the HTTP client in the HTTP request. Today, the default is the HTTP Java request, but it has the following issues: * HTTPS less efficient than HC3 or HC4 * No possibility to change source IP Implementation HC 3.1 is stable and reliable The implementation HC4 is (relatively) recent in JMeter. And there were some anomalies in the past. I think the next version of JMeter could have HC3.1 as a default implementation. (Or if you want to be bold, have HC4) What's is your opinion? Milamber
Re: Change the default implementation of HTTP in HTTP request ?
That's probably a bug in JMeter ... doh ^^ but it's controller-specific, it works with HC4, but no other ;) Just put the full URL in the Path field. lol, never considered that, will try it out tomorrow at work :)
Re: Listening for end of test run?
I assumed from your original post that you were running a batch job, i.e. running JMeter in batch (non-GUI) mode. If not, you should be. I must confess, I didn't yet look into the non-gui mode (yet) In which case, just add the mail step after the test finishes. of course I can then just mail the file, but it won't have nice graphics (eg. green ticks, red crosses) ... that's why I'm envisioning some kind of checklist mail which is easy and fast to look at eg. total executed: 18 passed: 15 failed: 3 test1 check test2 check test3 failed [...] I don't think you *need* a Listener to solve your requirement. [rant] I also don't need JMeter to run my tests (any standard programming language can do http requests just as well), but it's the best/fastest tool to do the job ... which is exactly my point with why I'd love to see this as a listener: because it would be imho the best solution to have a listener integrated that creates good and easy to look at mails to allow for greater automation. Also note that we are not discussing if this (potential) feature should be merged upstream or not which will be the topic of another thread should I succeed in what I want to do. [/rant] Anyhow, the general question still remains: is there some way to detect the end of a testset run (when the thread(s) that the component is associated with is(are) finished)?
