Hi I would argue that many users will benefit from adding a metric to calculate the sent bytes for PUT and POST. I was wondering can someone create a bug for this (or point me to how to create one? I have not created a jmeter bug before). Is there anytime line for this functionality? thanks Ahmad
> Subject: Re: HTTP PUT bytes output does NOT include the uploaded file size > To: [email protected] > From: [email protected] > Date: Sat, 1 Oct 2016 21:36:34 +0200 > > HI , > > thumbs up for a new metric measuring output bytes. > It should not break any current report, but I have this need very often. > It is a common requirement for many application types like document > management. > Also, it is not so simple to forecast the output size, when considering > cookies, headers, content compression, etc. > > Regards > Sergio > > Il 01/10/2016 14.57, Philippe Mouawad ha scritto: > > Hello, > > See discussion "Add a new metric : sent bytes", there have been some > > feedback on this proposal. > > > > Even if it's some work, I believe it should be here. > > I am often asked to provide the outgoing traffic from JMeter. > > To provide it I have to rely on 3rd party tools. > > It would be nice to have it as we currently have a report that graphs > > incoming bytes. > > > > Regards > > > > On Sat, Oct 1, 2016 at 2:52 PM, sebb <[email protected]> wrote: > > > >> On 1 October 2016 at 08:35, Ivan Rancati <[email protected]> wrote: > >>> I would suggest: > >>> > >>> write a sampler in Java that does the http put, then you can access the > >>> Response object and set the size to a value you specify. > >>> I think it would also work with the scripting samples (like Beanshell, > >>> Javascript) > >>> > >>> I personally don't think there is anything to fix, as all samplers return > >>> the size of the response, and it would be confusing to have a model where > >>> the size is sometimes the request, sometimes the response, or a mix of > >> the > >>> two. I'm a JMeter user, not a developer, so that's just my opinion, maybe > >>> I'm missing something obvious > >> You have put it very well. > >> JMeter measures the server response size. > >> > >> I suppose there could be an option to include the request size, but > >> that would be a fair amount of work to add. > >> It's obviously not a huge need, otherwise there would have been more > >> requests to add it (and maybe a patch or two). > >> > >> Note that the size of file uploads will generally be known by the > >> tester, so can be allowed for if necessary. > >> Whereas the server response size is not known until the request completes. > >> > >>> On Fri, Sep 30, 2016 at 8:54 PM, Ahmad A <[email protected]> wrote: > >>> > >>>> Hi IvanThank you for your prompt response. > >>>> The content-length that is being returned with the PUT request is > >>>> actually > >>>> 0 > >>>> Content-Length: 0 > >>>> So I am guessing Jmeter is calculating the response size of all the > >>>> headers and text returned which is consistent with the 464 bytes recorded > >>>> for all object PUTs. This calculation of bytes for PUT is not correct > >>>> since > >>>> the measurement needs to be the amount of data sent (PUT, POST) not > >>>> received (GET). > >>>> Is it possible to get this fixed?? > >>>> thanks > >>>> Ahmad > >>>> > >>>> > >>>>> From: [email protected] > >>>>> Date: Fri, 30 Sep 2016 20:39:46 +0200 > >>>>> Subject: Re: HTTP PUT bytes output does NOT include the uploaded > >>>>> filesize > >>>>> To: [email protected] > >>>>> > >>>>> I would imagine JMeter returns the size of the http response, not the > >>>> size > >>>>> of the uploaded data. > >>>>> What does the Content-Length header return for your request? > >>>>> I would imagine it's a constant number, regardless of how many bytes > >> you > >>>> PUT > >>>>> Example with wget, it's similar with curl > >>>>> wget -S -O /dev/null --method=PUT > >>>>> --body-data="123456789012345678901234567890 > >>>> 123456789012345678901234567890" > >>>>> http://... > >>>>> > >>>>> best regards > >>>>> Ivan > >>>>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > > -- > > Ing. Sergio Boso > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
