Deployment and Imaging Group

 View Only
  • 1.  DS 7.1 Performance

    Posted Sep 30, 2011 04:26 PM

    So I've finally managed to duplicate the functionality of our image build/deployment process used in DS 6.9.  We use automated build jobs with tasks to install each software component and settings change to a base OS image.  Then we take an image of that and have a seperate deploy job which adds machine-specific software and settings.

    Right now I'm specifically focusing on the depoyment job.  Our Win7 standard image deployment job on 6.9 takes 15-20 minutes to deploy the image and install the additional software and settings.  This same process in 7.1 takes 45 minutes to an hour.  Most of this seems to be due to the fact that it takes 7.1 SO much longer to fire and respond to tasks.  Round trip on a single task is at least twice as long.

    My question is, is there a way to tune this at all for smaller shops where the additional overhead to speed things along wouldn't bring things crashing down?



  • 2.  RE: DS 7.1 Performance

    Posted Oct 03, 2011 09:14 AM

    If the main delay you're seeing is waiting for jobs to arrive, then right now, there's not much you can reasonably do.  You could script far more, which would reduce the number of tasks to run and therefore avoid some of the delays, but that's about all.

    I know that part of what you're looking for we are trying to accomlish with some redesigns in the product, but those are still in the design / discussion phase, no where NEAR reality.  

    However, if you have a specific delay you're chasing, we may be able to help that.  For instance, if you add on 40 minutes to the process, that's pretty significant.  Is this all coming from a particular delay, perrhaps in WinPE or something?  Where is all that time actually coming from?



  • 3.  RE: DS 7.1 Performance

    Posted Oct 04, 2011 01:27 PM

    Most the delays appear to be behind the scenes.  Some are from additional things we have to do that used to be automatic in 6.9 (for instance hardware inventory was run in the WinPE agent whereas now we have to manually run it in production).  There is a much longer delay in all phases of tasks except actual run-time on the client (delivery to the client,  delivery of result to the server, processing conditions (if any) on the result).  It sounds like the delivery phases just take longer because it's NS. :(

    The most problematic for us is the delivery delay occurs whenever a condition is used.. basically it seems to take up the delivery time of a whole other task even though it shouldn't, as far as I can tell, involve any communication with the client agent.  If we have to parse through a list of 15 return code conditions to determine which job to kick off next, the job takes a large chunk of time, unlike in 6.9 where no matter how many return codes you handled, it was a finite time (near instantaneous) to trigger the handler and fire off the next job.  

    Perhaps it's the current design of conditions.. right now there's only if-else.  A lot of times (arguably any time you have more than two expected results for the same return code) a select-case handled in one transaction would be much more efficient than nested ifs handled in separate transactions.

    Just so you have an idea of the timing I'm talking about, here's a run-through of one of our condition-heavy jobs:

    (five seconds elapse between job start and T1 being fired)

    T1: map a drive (takes 10 seconds, then 10 seconds elapse before next task fires)

    T2: run a script to determine machine location, type and manufacturer, exits with appropriate return code (takes 10 seconds, then 10 seconds elapse before next task fires)

    C1: If T2 returns 100, do nothing (falls out to a task T4 at the bottom of the job) (takes 0 seconds, +10 seconds elapse before next condition fires)

    else 

        T3: Gather hardware inventory (takes 1:15+10)

        C2: If T2 returns 111, run System Configuration task A, (for instance St Louis Dell Desktop, let's call it SC:A) (takes 0+10)

        else C3: If T2 returns 121, run SC:B (0+10)

            else C4: If T2 returns 113, run SC:C (0+10)

                else C5: If T2 returns 122, run SC:D (0+10)

                    else C6: If T2 returns 123, run SC:E (0+10)

                        else C7: If T2 returns 130, run SC: F (0+10)

                        condition fires: SC:F is run (takes 10 seconds, then machine is rebooted, taking 2:30)

    <end of conditions>

    T4: Unmap drive (takes 10 seconds, then 10 )

    The entire job takes 5:23, which adds up with just a few extra seconds to rounding errors.  So there you have it, two minutes of the job was time wasted in 5-10 second intervals between tasks and conditions.  And this is only one office.  When I finish adding in conditions for our other offices we'll triple the amount of conditions and the job will potentially take an additional 3-4 minutes on machines in the last office.



  • 4.  RE: DS 7.1 Performance

    Posted Oct 04, 2011 02:45 PM

    Ideally, we'd do this with VBS, but you're trying to fire off other system config tasks, and that makes sense.  I don't know where we'd want to go with that, but I'll bring it up.

    I know there are issues with conditions already being re-worked, but I don't know if anyone has brought up that use-case before.  I'll see what I can find out.



  • 5.  RE: DS 7.1 Performance

    Posted Oct 04, 2011 03:39 PM

    This has me interested...

    From a backend/NS perspective, can you explain why every conditional listed above takes an extra 10 seconds?  Why aren't those conditionals executed as one?  Either sending the whole IF/ELSE conditional to the client to process at once, or even sending the variable back to the NS for immediate conditional testing, seems like a much better idea.



  • 6.  RE: DS 7.1 Performance

    Posted Oct 05, 2011 10:06 AM

    Otherwise, I'd not have to bring that up with development.  This is something we've not had complaints about.   Truth is, MOST who have used this are using very simple logic, so the comlaint hasn't been logged, that I know of.



  • 7.  RE: DS 7.1 Performance

    Posted Oct 05, 2011 10:27 AM

    To be honest the only reason we've put forth the tremendous effort so far required to port our jobs over from 6.9 was because of the new conditions and ability to call jobs from other jobs.  We've been doing this sort of thing with job "chaining" (having a job run a script that does some calculation, then exits with a handled error code to call another job in the chain) in DS 6.9 for years, without the ability to view the whole job chain in one interface (a major pain, considering some of our chains are 50+ jobs long).  It kind of floors me that no one else is using it.. I fail to see any other real benefit to 7.1 DS over 6.9, and a whole LOT of things that don't work as well (yet).

    Anyway, if the devs need some more feedback from us since we seem to be utilizing rather more of the features than anyone else, send them our way.  We have a vested interest in getting it fixed to work the way we want it to. :)