jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinoth raj <vinoth....@gmail.com>
Subject Re: LengthPrefixedBinaryTCPClientImpl issue
Date Tue, 17 Jun 2014 17:58:26 GMT
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 am checking on Ethernet for which the MTU is 1460 bytes so there is no
chance of exceeding the limit too.

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.



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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message