|
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 :)
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 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?
Or is this using a more generic tool like E-mail, HTTP or FTP?
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.
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.)
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.
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.
But, since it's very easy to try, you might set these to 128k and see if it makes a difference.
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.
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.
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.
midrange.com
