locked
APPS-V Launching RRS feed

  • Question

  • We have began rolling out apps-v and wanted to hear what to expect from our deployment from other people respoinsible for maintaining these systems.

    We are Sequencing apps like adobe reader and office, and it seems it takes a good bit longer to lauch these apps than if they were straight up loaded from CD. Is it normal for office or adobe to take 10 seconds to lauch where if they were normal apps it would be shorter?

    Thursday, March 26, 2009 2:19 PM

Answers

  • Hello,

    Utilizing the full-infrastructure model I have experienced these issues.

    Utilizing stand-alone I have not.

    This is of course dependt on many things, and I can't say that one is better than the other. Full-infrastructure is depedent on so many factors that its not that easy to determine what causes a delay, standalone removes many of these.

    Currently I am working in a full-infrastucture model which has no issues dependt on the infrastructure, we still do have issues - usually caused by networking issues due to a decentralized home-folder structure.

    /Znack
    • Proposed as answer by znack Thursday, April 16, 2009 6:27 AM
    • Marked as answer by Aaron.ParkerModerator Saturday, November 17, 2012 3:40 PM
    Thursday, March 26, 2009 3:10 PM
  • Two main reasons for abnormal delay in launching (when in full infrastructure):

    1) Slow connection to server, as client always tries to talk to server for each launch thus slowing down the launch. You can expirement with setting "Work offline" to on, which eliminates this delay, and see if it makes a difference

    2) Automatically started virtual services, these get started before launching of actual program commits

    You can look at client's logfile (sftlog.txt) and see how long it took to bring up VE (with default logging level, this piece of information is written to logfile), which could be the third reason for slowness. The bigger VE (i.e. virtual registry and VFS mappings), the longer it takes to "upload" it.

    br,
    Kalle
    • Proposed as answer by znack Thursday, April 16, 2009 6:27 AM
    • Marked as answer by Aaron.ParkerModerator Saturday, November 17, 2012 3:40 PM
    Thursday, April 9, 2009 8:27 AM
    Moderator
  • When looking at launch times, you may need to visit delays that happen behind the management server RTSP connection.  Sql, then AD.   Also note that testing a client virtualized on something like Hyper-V may produce significantly different results than a physical client (meaning your end users might not see most of that 10 seconds).
    • Proposed as answer by znack Thursday, April 16, 2009 6:27 AM
    • Marked as answer by Aaron.ParkerModerator Saturday, November 17, 2012 3:40 PM
    Saturday, April 11, 2009 12:30 PM
    Moderator

All replies

  • Hello,

    Utilizing the full-infrastructure model I have experienced these issues.

    Utilizing stand-alone I have not.

    This is of course dependt on many things, and I can't say that one is better than the other. Full-infrastructure is depedent on so many factors that its not that easy to determine what causes a delay, standalone removes many of these.

    Currently I am working in a full-infrastucture model which has no issues dependt on the infrastructure, we still do have issues - usually caused by networking issues due to a decentralized home-folder structure.

    /Znack
    • Proposed as answer by znack Thursday, April 16, 2009 6:27 AM
    • Marked as answer by Aaron.ParkerModerator Saturday, November 17, 2012 3:40 PM
    Thursday, March 26, 2009 3:10 PM
  • Two main reasons for abnormal delay in launching (when in full infrastructure):

    1) Slow connection to server, as client always tries to talk to server for each launch thus slowing down the launch. You can expirement with setting "Work offline" to on, which eliminates this delay, and see if it makes a difference

    2) Automatically started virtual services, these get started before launching of actual program commits

    You can look at client's logfile (sftlog.txt) and see how long it took to bring up VE (with default logging level, this piece of information is written to logfile), which could be the third reason for slowness. The bigger VE (i.e. virtual registry and VFS mappings), the longer it takes to "upload" it.

    br,
    Kalle
    • Proposed as answer by znack Thursday, April 16, 2009 6:27 AM
    • Marked as answer by Aaron.ParkerModerator Saturday, November 17, 2012 3:40 PM
    Thursday, April 9, 2009 8:27 AM
    Moderator
  • When looking at launch times, you may need to visit delays that happen behind the management server RTSP connection.  Sql, then AD.   Also note that testing a client virtualized on something like Hyper-V may produce significantly different results than a physical client (meaning your end users might not see most of that 10 seconds).
    • Proposed as answer by znack Thursday, April 16, 2009 6:27 AM
    • Marked as answer by Aaron.ParkerModerator Saturday, November 17, 2012 3:40 PM
    Saturday, April 11, 2009 12:30 PM
    Moderator