jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: LengthPrefixedBinaryTCPClientImpl issue
Date Thu, 19 Jun 2014 14:19:18 GMT
On 18 June 2014 07:12, Vinoth raj <vinoth.amu@gmail.com> wrote:
> JMeter (and TCP) do not guarantee that the data will be sent in a single
> packet. -- I agree
>
> The only thing I see now is to handle things on server side.
> As it can be found in the log in my last message when I try to send 131
> bytes of data then in the log I indeed find "Wrote 131 bytes".
> So, the log trace does not tell how the 2 bytes of data length was actually
> sent.
>
> I was wondering if it is possible to know how Jmeter handles sending of
> data for length prefixed impl.
>

JMeter is open-source, so you can just read the source.
See the earlier posting from Jeff Ohrstrom which includes details of
the relevant lines.

If you want to know how that translates to packets on the wire, then
you can use a protocol analyser such as WireShark.

>
>
>
>
> On Wed, Jun 18, 2014 at 1:03 AM, sebb <sebbaz@gmail.com> wrote:
>
>> On 17 June 2014 18:58, Vinoth raj <vinoth.amu@gmail.com> wrote:
>> > Sebb,
>> >
>> > I do understand that two TCP requests can be merged in kernel buffer
>> > internally.
>> > Also, based on the MTU, data in single request can span multiple recv on
>> > server side.
>> >
>> > What I am surprised is that when you send data of say 131 bytes I do not
>> > see any reason for splitting it into two request.
>>
>> I don't know why either, but that is not really the point.
>>
>> > I am checking on Ethernet for which the MTU is 1460 bytes so there is no
>> > chance of exceeding the limit too.
>>
>> However, there are other reasons why TCP may split transmissions into
>> separate packets.
>>
>> The application should be prepared to accept multiple packets.
>>
>> > For instance, here is the log of what is sent:
>> >
>> --------------------------------------------------------------------------------------------------------
>> > 2014/06/17 23:13:34 INFO  - jmeter.engine.StandardJMeterEngine: Thread
>> will
>> > start next loop on error
>> > 2014/06/17 23:13:34 INFO  - jmeter.threads.ThreadGroup: Starting thread
>> > group number 1 threads 1 ramp-up 0 perThread 0.0 delayedStart=false
>> > 2014/06/17 23:13:34 INFO  - jmeter.threads.ThreadGroup: Started thread
>> > group number 1
>> > 2014/06/17 23:13:34 INFO  - jmeter.engine.StandardJMeterEngine: All
>> thread
>> > groups have been started
>> > 2014/06/17 23:13:34 INFO  - jmeter.threads.JMeterThread: Thread started:
>> > Sample Test 1-1
>> > 2014/06/17 23:13:34 INFO  - jmeter.services.FileServer: Stored:
>> datahex.csv
>> > 2014/06/17 23:13:34 DEBUG -
>> > jmeter.protocol.tcp.sampler.LengthPrefixedBinaryTCPClientImpl: Wrote: 131
>> > bytes
>> > 2014/06/17 23:13:34 DEBUG -
>> > jmeter.protocol.tcp.sampler.BinaryTCPClientImpl: Wrote:
>> >
>> 7b22616374696f6e223a322c22757365724e616d65223a2256696e6f74682052616a222c2275736572507764223a2276696e6f746833383832222c22757365724c6f63223a224e657720596f726b222c227573657254797065223a2232303230222c226461746554696d65223a2230362f30362f323031342031333a31383a3235227d
>> > 2014/06/17 23:13:35 DEBUG -
>> > jmeter.protocol.tcp.sampler.LengthPrefixedBinaryTCPClientImpl: Read: 116
>> >
>> 7b22616374696f6e223a322c22726573756c74223a2273756363657373222c22674c696e6b223a2268747470733a2f2f496e6469612e566964656f436f6e66546563682e636f6d2f666c65782e68746d6c3f726f6f6d6469726563742e68746d6c266b65793d41614547687141494549584b227d
>> > 2014/06/17 23:13:35 INFO  - jmeter.threads.JMeterThread: Thread finished:
>> > Sample Test 1-1
>> > 2014/06/17 23:13:35 INFO  - jmeter.engine.StandardJMeterEngine: Notifying
>> > test listeners of end of test
>> > 2014/06/17 23:13:35 INFO  - jmeter.services.FileServer: Close:
>> datahex.csv
>> > 2014/06/17 23:13:35 INFO  - jmeter.gui.util.JMeterMenuBar:
>> > setRunning(false,*local*)
>> >
>> -------------------------------------------------------------------------------------------------------------------
>> >
>> > The actual data is of 131 bytes. The above log does not specify if the
>> data
>> > length was sent as separate request.
>> > However, it is noteworthy that on the server side I first get 2 bytes and
>> > then the 131 bytes data.
>>
>> JMeter (and TCP) do not guarantee that the data will be sent in a single
>> packet.
>>
>> IMO the application needs to be able to handle multiple packets.
>>
>> >
>> >
>> > On Tue, Jun 17, 2014 at 10:58 PM, sebb <sebbaz@gmail.com> wrote:
>> >
>> >> On 17 June 2014 08:41, Vinoth raj <vinoth.amu@gmail.com> wrote:
>> >> > Your response is really interesting.
>> >> > I already tried with log_level.jmeter.protocol.tcp=DEBUG setting and
>> also
>> >> > looked into LengthPrefixedBinaryTCPClientImpl class.
>> >> > I too found that there were two writes. But not sure if the two writes
>> >> > correspond to two sends.
>> >>
>> >> I don't think you can guarantee that the TCP stack will send a single
>> >> packet.
>> >> Or indeed that the TCP stack will send two packets for two writes,
>> >> even if you flush both writes.
>> >> TCP can perform whatever joining and splitting of data it deems
>> necessary.
>> >>
>> >> So I think the problem will have to be addressed in the application.
>> >> Otherwise it may work with JMeter but fail to work in some other
>> situation.
>> >>
>> >>
>> >> > But the above setting I was unable to see the data length being sent
>> as a
>> >> > separate request.
>> >> > Anyhow, I will set the settings you have specified and will analyse
>> and
>> >> > share the log details.
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Jun 17, 2014 at 12:49 PM, Jeff Ohrstrom <
>> johrstrom@hotmail.com>
>> >> > wrote:
>> >> >
>> >> >> I could be mistaken, but it would appear that in the code it calls
>> >> >> OutputStream.write twice and this could be causing your issue,
>> although
>> >> >> flushing on the second time, the JVM could have decided to flush
>> after
>> >> >> the first write call. I list the debug settings here, but a tcp
dump
>> may
>> >> >> be necessary to see if there are 1 or 2 packets being written out
on
>> the
>> >> >> wire (Java tends to abstract that).  Could it be that 2 packets
>> means to
>> >> >> 'recv' calls (and 1 packet is 1 recv call)?
>> >> >>
>> >> >> I would add the debug lines to see what they say it's doing:
>> >> >>
>> >> >>
>> >>
>> log_level.org.apache.jmeter.protocol.tcp.sampler.LengthPrefixedBinaryTCPClientImpl=DEBUG
>> >> >>
>> >>
>> log_level.org.apache.jmeter.protocol.tcp.sampler.BinaryTCPClientImpl=DEBUG
>> >> >>
>> >> >> From LengthPrefixedBinaryTCPClientImpl.java:
>> >> >>     @Override
>> >> >>     public void write(OutputStream os, String s)  throws IOException{
>> >> >>
>> >> >> os.write(intToByteArray(s.length()/2,lengthPrefixLen));    //first
>> write
>> >> >>         if(log.isDebugEnabled()) {
>> >> >>             log.debug("Wrote: " + s.length()/2 + " bytes");
>> >> >>         }
>> >> >>         this.tcpClient.write(os, s);        //second write
>> >> >>     }
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Mon, 2014-06-16 at 20:06 +0530, Vinoth raj wrote:
>> >> >> > Thanks for the response.
>> >> >> > I indeed send hex-encoded string only.
>> >> >> > The length of the message is something the Jmeter calcultates
>> based on
>> >> >> the
>> >> >> > text in put in Text to Send field. So, I guess I need not
worry
>> about
>> >> >> that.
>> >> >> >
>> >> >> > So, when I send the hex encoded data, on the server side I
get
>> first
>> >> >> > message as the message length and the second message the actual
>> data.
>> >> So
>> >> >> > one request on Jmeter side leads to two "recv" calls on server
>> side.
>> >> >> >
>> >> >> > Could you explain how to receive the complete request in one
single
>> >> recv
>> >> >> > call?
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Sat, Jun 14, 2014 at 6:14 PM, 黄吉浩 <13651877684@163.com>
wrote:
>> >> >> >
>> >> >> > > I think I understand you, and I try to clarify this problem
by
>> >> example:
>> >> >> > > when using "LengthPrefixedBinaryTCPClientImpl" as the
"TcpClient
>> >> >> > > classname", the input in "Text to send" should be hex-encoded
>> >> string.
>> >> >> > > i.e. if you want to send 1-byte message of 'A' to server,
so the
>> >> "Text
>> >> >> to
>> >> >> > > send" should be "41" (hex-representation of 'A')
>> >> >> > > and what Jmeter do is:
>> >> >> > > 1, caculate the actual length of contents in "Text to
send",
>> that is
>> >> >> 2/2 =
>> >> >> > > 1 ('A' occupys 1 byte, but representation "41" occupys
2 byte, so
>> >> 2/2)
>> >> >> > > 2, populate the value of lengh(here is 1) in 2 bytes
and send to
>> >> your
>> >> >> > > server (supposed u r using default, that is,
>> >> >> > > tcp.binarylength.prefix.length=2 in jmeter.properties)
>> >> >> > > 3, send the 1-byte message body to ur server
>> >> >> > > that's all.
>> >> >> > >
>> >> >> > >
>> >> >> > >
>> >> >> > >
>> >> >> > > At 2014-06-13 00:14:26, "-Vinoth raj" <vinoth.amu@gmail.com>
>> wrote:
>> >> >> > > >Hi All,
>> >> >> > > >
>> >> >> > > >I am trying to send a message to my server application
>> developed in
>> >> >> C++
>> >> >> > > >using LengthPrefixedBinaryTCPClientImpl class.
>> >> >> > > >
>> >> >> > > >On the server side I get the length and data in two
recv (socket
>> >> >> function)
>> >> >> > > >calls.
>> >> >> > > >I presume that normally this is not the case as the
first two
>> bytes
>> >> >> of the
>> >> >> > > >data itself should contain the data length.
>> >> >> > > >
>> >> >> > > >EXAMPLE:
>> >> >> > > >For example, if I send 131 bytes data Jmeter should
send 133
>> bytes
>> >> >> with
>> >> >> > > the
>> >> >> > > >first two bytes containing the data length.
>> >> >> > > >On enabling debug mode for the TCP sampler I found
that the
>> actual
>> >> >> data
>> >> >> > > >sent is logged as 131.
>> >> >> > > >
>> >> >> > > >Also, strangely if I run both Jmeter and the server
application
>> on
>> >> >> same
>> >> >> > > >machine I see the expected behaviour. I actually
get 133 bytes
>> in a
>> >> >> single
>> >> >> > > >recv call.
>> >> >> > > >
>> >> >> > > >I would appreciate if anyone can shed light on the
actual
>> behaviour
>> >> >> of the
>> >> >> > > >Jmeter.
>> >> >> > > >
>> >> >> > > >Vinoth
>> >> >> > >
>> >> >>
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> >> >> For additional commands, e-mail: user-help@jmeter.apache.org
>> >> >>
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> >> For additional commands, e-mail: user-help@jmeter.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org


Mime
View raw message