On 13 October 2016 at 08:31, Ivan Rancati <[email protected]> wrote: > Hello, > > quick feedback on the UI. > in the "Sample Result Save Configuration" dialog box there is a new > checkbox (Save sent bytes count). > Perhaps the existing checkbox (Save bytes count) could be renamed to "Save > received bytes count" for extra clarity.
+1 Though it should be "byte count" rather than "bytes count" > The same goes for the headers of the generated .csv file, but perhaps > renaming an existing header might break compatibility with existing > reports. -1 for changing the csv file headers > thanks for the enhancement and best regards > Ivan > > On Sun, Oct 9, 2016 at 5:24 PM, Philippe Mouawad < > [email protected]> wrote: > >> Hello, >> Enhancement implemented in : >> https://bz.apache.org/bugzilla/show_bug.cgi?id=60229 >> >> You can test it and give feedback using nightly build: >> - http://jmeter.apache.org/nightly.html >> >> Regards >> Philippe M. >> >> >> -- >> Cordialement. >> Philippe Mouawad. >> Ubik-Ingénierie >> >> UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/> >> >> UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack> >> >> >> On Mon, Oct 3, 2016 at 5:18 PM, Ahmad A <[email protected]> wrote: >> >> > 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] >> > > >> > >> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
