|
midrange.com
> The client builds a variable length string which contains many self
> described data items, including base-64 encoded images, that will
> typically be in the 1 - 1.5 meg range total. The transmission takes
> around 3 minutes on a 100mb Ethernet and about the same on a 11mb
> wireless.
>>Wow. Are you sure you're not using a 4800 baud modem? That's about the
>>speed you're getting :)
Kinda like a trip back in time huh?
> The windows client notes the time before it 'sends' and after
> it returns yielding an elapsed several minutes. The iSeries only
> becomes aware of the data several minutes after the windows client turns
> it loose, and decomposes and saves the data in just a few seconds.
>>I'm not following this... how can the iSeries only become aware of the
>>data several minutes afterwards? The Windows client is actually
>>CONNECTING to the iSeries, isn't it? How can it connect without the
>>iSeries being aware of it?
I just mean that the socket server sits there not using any cpu until
nearly the entire 3mins are gone and then 'suddenly' sucks cpu strongly for
several seconds processing the data then becomes quiescent again.
>>I guess I don't have a clear picture of what's happening. Is it simply a
>>Windows program that makes a TCP connection to an iSeries program, and
>>then sends the data through that connection?
Precisely!
>>Or is this using a more generic tool like E-mail, HTTP or FTP?
No.
> The same network will behave normally for ftp up/downloads. One of the
> clients can download a 20meg file in a few seconds - less time than it
> takes to save this 1-1.5 meg data.
>>So it's not a network problem, then. I suspect that the difference between
>>the FTP that's working well and the other bit that's not working well is
>>that you have different software involved. You have a different program
>>on both the Windows and iSeries side. I would suspect that those programs
>>are the place you should start looking... one of them isn't very
>>efficient.
I wish I could find a problem. the vb program (snippet):
Public Sub SendData(ByVal data As String)
Try
Dim BeginTime As DateTime = Now
Dim writer As New IO.StreamWriter(Client.GetStream)
Dim FilePath as String = InitLoadProperties.TodaysDate +
"_timer.txt"
LogIT(" Begin SendData: [" + data.Substring(20, 20) + "] ",
FilePath)
writer.Write(data)
writer.Flush()
LogIT(" End SendData - Time Difference: " +
DateDiff(DateInterval.Second, BeginTime, Now).ToString + " Seconds",
FilePath)
Catch ex As Exception
HandleException(ex)
End Try
End Sub
Logs Before and after the write which takes about 3mins. On the iSeries at
about 2:55 elapsed, the server sucks up some cpu and processes the data.
>>Check that neither one is sending/receiving one byte at a time. One
>>common problem I've found is that people will write a loop that calls
>>recv() for one byte at a time, and this is very slow. (Though, it's
>>partially my own fault, since I've written code that demonstrated doing
>>things that way, because it's simple and easy to understand.)
the iSeries server reads and writes as much as it can get/put at a time
to/from a user space. It just seems to be waiting on the incoming data for
an unusually long time and I haven't yet figured out why.
>>Instead, they should read a bigger chunk, maybe 32k, with the recv() API,
>>then substring the result to get one byte at a time (if that's what they
>>need). When they run out of data, read another chunk.
It's in a loop reading as much as it can get in each pass until it gets the
agreed upon total - it reads directly into a user space.
> Anybody have any suggestions as to where to start? My iSeries has :
>
> TCP receive buffer size . . . . 8192
> TCP send buffer size . . . . . . 8192
>>I doubt very much that changing these will make a big difference. Also,
>>remember that applications can override these sizes by calling the
>>setsockopt() API. These are, therefore, only defaults.
I just figured someone would ask...
>>But, since it's very easy to try, you might set these to 128k and see if
>>it makes a difference.
Yeah, it doesn't take much to try - I'll give it a try...
> and the windows is more like 1k but this doesn't seem like enough for this
> kind of slowdown...??? I am way not a networking guru. Thanks for any
> ideas.
>>Yeah, I agree. I think it's more likely to be inefficient code. And
>>probably on the receiving end.
maybe you are right - if you wish I can show you the code (snippet):
C Eval DataPtr = UsrSpcPtr
C Clear MyData
C Clear BytesRead
C Clear BytesNeeded
C Clear BytesTotal
C Clear TestData
C Eval BufferSize = 16776704
* ---------------------------------------------------------------
* The Incoming Data Has the total data length in the 1st 10 bytes
* Get the first ten bytes in order to determine how much there is
* Then read the rest of the available data
* ---------------------------------------------------------------
C Eval BytesNeeded = 10
C Eval RecvTries = 0
* Read Persistently Until The Proper # Of Bytes Are Read
C DoW BytesTotal < BytesNeeded
C Eval BytesRead = recv(Socket#2 :
C DataPtr :
C BufferSize:
C 0 )
* If we have read the first 10 bytes, convert them to see The Total
C If Bytesread >= 10
C And testData = *Blanks
C Move MyLenA TestData
C If Ascii
C CallP XlateBig( 10 : %Addr(TestData) :
'QTCPEBC')
C EndIf
C Move TestData BytesNeeded
C EndIf
* If There was a read error or no data pause for a couple of seconds
C If Bytesread <= 0
* If There was a read error or no data pause for a couple of seconds
C If Bytesread <= 0
C Call(e) 'SLEEPCL'
C Parm '000001' Delay
C Eval RecvTries += 1
* If I've Tried for 8 Hours (or more) - Give Up
C If RecvTries > 28800
C Eval Done = *On
C Eval LMsg = %Trim(WhoIsIt) +
C ' ' + %Trim(LUser)
C + ' Receive Timed Out In ConRep02 - '
C + ' ~ '
C CallP SndLogErr(Lmsg)
C ExSr GetMsg
C ExSr Exit
C Return
C EndIf
C EndIf
* Bump the Space Pointer the amount read As We Go And
* Sum The Bytes Read For Total To Compare to BytesNeeded...
* Decrement the Buffer Size
C If BytesTotal < BytesNeeded
C And BytesRead > 0
C Eval BytesTotal += BytesRead
C Eval DataPtr += BytesRead
C Eval BufferSize -= BytesRead
C EndIf
C EndDo
* Reset The Space/Data Pointer To The beginning of the User Space
C Eval DataPtr = UsrSpcPtr
* When All Data Is Read, DeCipher it to Prepare For Translation
C If EnCrypt
C Eval EnCryptLen = BytesTotal
C If Not Cipher( EnCryptLen:
C DataPtr :
C '1' )
C Eval errnoP = errnoF
C Eval EPtr = Strerror(errno)
C Null:' ' XLate(e) ErrMsg ErrMsg
C Eval LMsg = %Trim(ErrMsg)
C + ' Returned From Cipher In ConRep02 - '
C + '(Receive)~'+%Trim(MyData)
C CallP SndLogErr(Lmsg)
C ExSr GetMsg
C EndIf
C EndIf
* Once DeCrypted, Convert it to EBCDIC For Processing
C If Ascii
C CallP XlateBig( BytesTotal :
C DataPtr :
C 'QTCPEBC' )
C EndIf
* --------------------------------------------------------------------
CSr ENDSR
* --------------------------------------------------------------------
Let me know if you need to see more and what it might be that draws you
interest...
>>
>>Calling the send() or recv() API in WinSock (Windows Sockets) with only
>>one byte at a time can have HORRENDOUS effects on performance. It makes a
>>bigger difference there than it does on the iSeries, though it's bad on
>>the iSeries as well. But, since Windows PCs tend to be extremely fast and
>>dedicated to what they're doing at the time, I have a feeling you'll find
>>the problem on the iSeries end.
It works for me... But what? <smile>
Thanks for your reply Scott.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
