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. On Wed, Jun 18, 2014 at 1:03 AM, sebb <[email protected]> wrote: > On 17 June 2014 18:58, Vinoth raj <[email protected]> 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 <[email protected]> wrote: > > > >> On 17 June 2014 08:41, Vinoth raj <[email protected]> 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 < > [email protected]> > >> > 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, 黄吉浩 <[email protected]> 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" <[email protected]> > 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: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> >> > >> > >> --------------------------------------------------------------------- > >> 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] > >
