3 Replies Latest reply on Apr 3, 2009 9:03 AM by phoffmann

    Very Slow File Transfer for a Software Distribution

    Apprentice

      For quite some time now, i have always created self-extracting archives for any package that has many small files (when i say many, for example i mean 80 files over 40mb so not really many at all).

       

      The reason i use these self extracting archives is because a software distribution transfering one 40 mb file is SOO much quicker that if the 40 mb is 80.

       

      As i watch the files appear in the sdmcache folder, they appear at about 1 file every one or two seconds - i.e very slow.  This is on a test machine on the same gigabit switch as the core server.

       

      File transfers using windows in general are not slow, it is only landesk transfering the files that is the problem.

       

      Anyone else experienced the same behaviour?  Does anyone have a fix?

        • 1. Re: Very Slow File Transfer for a Software Distribution
          phoffmann SupportEmployee

          This is "normal", Mike.

           

          When we try to get ahold of "a file", there's a fair bit of communication involved.

           

          * Do we have it in the local cache, yes/no?

          * Does a peer have the file (and all the handshaking involved with that - yes/no?

          * What about a preferred package server.

           

          Finally, once we've downloaded the file, we need to hash it and check against the hash value it's supposed to have, to make sure it's the right one and didn't go bad. So a lot of overhead goes into timeouts, handshaking, etc. etc....

           

          And this happens for every file. This is why wrapper-packages are very useful, because you're only doing the whole network-communication once.

           

          There's good reasons for doing this for "every single file" (I've had instance where some PC's for instance only had 50 out of 100 files in their cache), which essentially boils down to us trying to make as sure as possible that you WILL get the right file. This does cause overhead, and "high quantities of small files" is going to be VERY much worse compared to a nice "wrapper package".

           

          Hope this explains things to you .

           

          I supposed the "fix" if you so want, would be using "Run From Source", which would work around all this, but then you run into all sorts of other potential problems . It's really down to what poison you prefer .

           

          Paul Hoffmann

          LANDesk EMEA Technical lead

          • 2. Re: Very Slow File Transfer for a Software Distribution
            Apprentice

            In which case, the ability to create multi-stage tasks encorporating up to 3 different software packages is limited because if you try to use self-extracting archives, it will start to process the subsequent package after the first one completes extracting, not when it has completed the install.  Is there anyway of introducing a delay between the processing of the different packages?

            • 3. Re: Very Slow File Transfer for a Software Distribution
              phoffmann SupportEmployee

              Batch file based installs, come to mind (with the compressed packages being additional files).

               

              They run perfectly sequentually, and allow you to run things in the order you want.

               

              Unless I'm oversimplifying and somehow being a plank and thus missing what you're talking about (it being Friday afternoon - quite possible) .

               

              Paul Hoffmann

              LANDesk EMEA Technical Lead