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 Tue, 17 Jun 2014 19:33:11 GMT
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


Mime
View raw message