11 Replies Latest reply on Apr 26, 2012 9:57 AM by jaericho

    Seeking Explanation for Slow Build of Package Cache on Clients / Hash Checking

    Rookie

      We're switching to LANDesk at my work and I've been having some frustration with slow additional file builds on machines. Pushing a 15MB application takes five times longer than it used to with our old deployment tool. I can watch the C:\Program Files\LANDesk\LDClient\sdmcache directory build additional files, at a rate of about 1 or 2KB/sec. My delivery methods are set for maximum speed/bandwidth consumption.

       

      Prior posts on this community suggest that the slowness is a result of the LANDesk client checking the hash of each individual file. My question is why does it take so long to check hashes? And is there any way to speed this process up? I've used ZENWorks, SCCM, Tivoli, Altiris, and Radia in past lives and I've never had an issue like this. I'm beginning to think it boils down to poor deployment agent design. But, I'm still open to helpful suggestions if anyone out there in the community has some to offer.

       

      Thanks!

        • 1. Re: Seeking Explanation for Slow Build of Package Cache on Clients / Hash Checking
          zman Master

          Andy,

           

          What version/SP/Post Patches are you running and what client OS?

          Within the 15MB package how many files?

          The rate seems extremely slow and is not the same in our environment. You can see where the file is being pulled from (peer, preferred server, or package source) by evaluating the sdclient log file for the job. You may be having issues pulling from a local peer.  To test you can always change your delivery method to run from package source.

          • 2. Re: Seeking Explanation for Slow Build of Package Cache on Clients / Hash Checking
            Rookie

            I'm runnning version 9.0.3.1 and this is on XP SP3 Pro.

             

            This package contains 34 files in 4 folders.

             

            I know this particular package isn't on any peers, so it's pulling from package source on a file server (confirmed in the sdclient_task log file).

            • 3. Re: Seeking Explanation for Slow Build of Package Cache on Clients / Hash Checking
              zman Master

              So there is a lot going on, checking hash, preferred server, checking local cache, checking peers, and the download.  So the overall process is slower than simply copying the file from the source to target.  In the sdclient log you should see the ILdDownloading file... and ILdDownloading returned 0. That is the actual download piece and it will be slower than a simple copy, but should not be excruciatingly slow. Small files seem to take about 2-3 seconds per download.  However, if it does not meet your needs:

              1. Create a one file distribution with autoit, inno, admin Studio, any self extractor.
              2. Try run package from source.
              • 4. Re: Seeking Explanation for Slow Build of Package Cache on Clients / Hash Checking
                Rookie

                Unfortunately that seems to confirm my suspicion that the distribution piece of LANDesk was just designed ineffciently. That's a shame. I guess I'll zip up my larger deployments.

                • 5. Re: Seeking Explanation for Slow Build of Package Cache on Clients / Hash Checking
                  jaericho Apprentice

                  Did something change in SP3?

                   

                  I am having similar issues. I'm noticing 7KB files taking 6-7s per file. And large files don't xfer any faster. The packages I'm using were working in SP2, but after upgrading to SP3 they are useless. Something must have broken software distribution in SP3.

                  • 6. Re: Seeking Explanation for Slow Build of Package Cache on Clients / Hash Checking
                    Catalysttgj Expert

                    Its a little extra work, but you might consider using a "custom definition" patch through the patch manager side of the house. We too experienced the slowness of small mulitple file packages and decided to steer towards the single zip file model. Its way faster in a multitude of ways, not limited to the client side execution. The gains of using custom definition patch method are wonderful as well, since the patch side actually supports a built-in zip unpack feature, so no need for complexity on creating any archive.

                     

                    A good example of performance improvement.. we once had a package that had around 1400 files that would take about 30-45 minutes to CREATE in a package, then about 2 hours to install on a client. (and this was back in 8.7 which was extra aweful). We took it to a single zip file in a package with an included unpacker utility, and the creation time dropped to near nothing, and the install time went to 15 minutes. We later began using custom definition method with this same package, which didn't save time, but it allowed dropping the need for an unpacker utility, which further simplified building all other packages in the same manner, but also we gained the benefits of querying and reporting on "detection", and "install date", and the other elements that a patch has in the DB, which is more instantaneous for measuring results of softare deployment as compared to a regular package installation where this sort of information is less available, and you have to wait for a software inventory to ultimately know how successful installs really are. There's always the task status itself, but i find that very limited in usefulness compared to patch status features.

                    • 7. Re: Seeking Explanation for Slow Build of Package Cache on Clients / Hash Checking
                      MarXtar ITSMMVPGroup

                      This isn't actually inefficient design (although there are ways to make it better), it is simply a bunch of stages and mechanisms that didn't exist in the other products. Not only is it checking the hash files, it is also checking where it should be getting the files from in order to be bandwidth efficient including identifying peers that might have the file in the cache. Since this can be any system rather than caching servers and each file could come from a different representative that also adds overhead. This only happens though if you are using a method that needs those features.

                       

                      Want something to go really fast and it is only going to a relatively small number of clients, then use a UNC source and run from source. It will fly then.

                       

                      If you want to use the bandwidth capabilities and send it to lots of people, then use 7zip to combine it into a single file and launch the install from the extracted file.

                       

                      You are right that in the method you are using it is slower than the others, but it has benefits the others don't have. If you are going to sit and watch this because you want to install it to one machine at a time, use a different method which is faster. Different methods work better for different scenarios.

                       

                      Mark McGinn

                      MarXtar Ltd

                      http://landesk.marxtar.co.uk

                      LANDesk Silver ESP

                       

                      The One-Stop Shop for LANDesk Enhancements

                      - Wake-On-WAN - Distributed Wake-On-LAN, Scheduled Power Down, and SWDist Sequencing

                      - State Notifier - Real-Time Device & User State Inventory Updating & Alerting

                      • 8. Re: Seeking Explanation for Slow Build of Package Cache on Clients / Hash Checking
                        zman Master

                        As Mark and I have stated there are numerous operations undertaken. Inefficient is somewhat subjective since all products are ineffective. Probably a better statement is "faster downloading". again LANDesk does offer more features with more overhead, especially in this case. It also offers a lot of flexibility in delivery (that has been stated above).  There is an ER for the feature to use single compressed files by default Option to compress Distribution Packages to a single file and if you think this a good ideal vote for the ER. It has never been very fast (relative to other delivery methodologies) with packages with numerous small files. 

                         

                        I still personally think we need an ER for the ER system since there are numerous items that are not being addressed, or not being updated within the system.

                         

                        Also somewhat related. AdmiStudio is great but for small projects it is a bear. I've found that Inno Setup is a great replacement for Package Builder, especially with the addition of an IDE.

                        Inno

                        http://www.jrsoftware.org/isinfo.php

                        Great IDE

                        https://www.kymoto.org/inno-script-studio/

                        • 9. Re: Seeking Explanation for Slow Build of Package Cache on Clients / Hash Checking
                          jaericho Apprentice

                          Want something to go really fast and it is only going to a relatively small number of clients, then use a UNC source and run from source. It will fly then.

                           

                          I get that there are lots of extra features in SDM (Multicasting, peer downloading and all that jazz), I just wish I could turn them off (if that is what is causing the slowdowns). We use riverbed products and qos to balance stuff out so turning off all the extra features and saying "download all from this unc share, hash it all, then install" would be ideal.

                           

                          I will be trying the run from share now.

                          • 10. Re: Seeking Explanation for Slow Build of Package Cache on Clients / Hash Checking
                            zman Master

                            Hmm we used to use RiverDead back in the day and it really would not work well with LANDesk, and other products. Things may have changed, don't know since we switched over to Cisco WAS.

                            • 11. Re: Seeking Explanation for Slow Build of Package Cache on Clients / Hash Checking
                              jaericho Apprentice

                              The only issue we've encountered with landesk/riverbed is that we can't extract the certificate from landesk core to import into riverbed, so all the agent traffic is not optimized. Caching any deployment files has always worked well since we are just coming off a unc share.