Not an FTP answer, but the two seconds difference is an age! I've seen a problem with long times where it took a long time to establish a session, because it had a DNS set up problem, and the requests were timing out, and trying another DNS server which worked. If you are using abc.xyz.org instead of 10.1.2.3 then try numbers.
Transfer a small file, and do a network trace to see where the time is being spent. You mentioned going from a dynamic loaded stub to a static loaded stub went down from 40 seconds to 31 seconds. bearing in mind it should take milliseconds to load a stub - not 10's of seconds something sounds wrong. Maybe you were doing load stub, unload sub, load stub unload stub etc..if each of those took 1 ms you may have done 9000 of these to give you the 9 seconds. Try load stub.. (load stub, unload stub) * n .. and the final unload . Once it has been loaded, a second load just increments a use counter. While use count > 0 it stays resident. (It needs to be reentrant etc) On Fri, 29 Oct 2021 at 00:46, Charles Mills <[email protected]> wrote: > It's not that classic FTP is slow; it's the FTP API that is unexplainably > slow. > > I have some hard numbers now. > > The IBM-supplied API sample program takes six elapsed seconds on the > Dallas z14. > > The classic FTP client performing EXACTLY the same transfers from INPUT DD > * with the same site (our Dallas machine via its IP address) took two > seconds. > > The sample program does a bit of processing of the data -- searching for > the largest file in the listing returned from DIR /tmp/* -- but that should > not account for four seconds. > > Would love to have an IBMer comment. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of kekronbekron > Sent: Tuesday, October 26, 2021 9:14 PM > To: [email protected] > Subject: Re: Performance issues with the FTP API > > There was a post within the past year about FTP being slow. > It came down to reverse DNS lookups I think. > Just something to look up perhaps. > > - KB > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Wednesday, October 27th, 2021 at 12:03 AM, Charles Mills < > [email protected]> wrote: > > > Questions for anyone who has used the z/OS FTP API: > > > > Are you seeing poor performance? For example, we are seeing FAPI_INIT > taking > > > > about four seconds (whereas the real FTP client starts up almost > > > > immediately). We are seeing a sequence of four RMDIR's taking about four > > > > seconds (on a local connection where the real FTP client does it > effectively > > > > instantaneously). > > > > A particular set of functionality -- start to finish -- takes about seven > > > > seconds with the real FTP client. A comparable functionality -- not > exactly > > > > the same, but roughly the same -- takes 31 seconds with the FTP API. > > > > Is this what others are seeing? Has anyone discovered any particular > > > > gotcha's? The programmer was loading the stub dynamically rather than > > > > statically, but fixing that only knocked it down from 40 seconds to 31. > > > > This is on a z14 under V2R4. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
