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]
