locked
Minimum req'd components for testing app-v5 streaming to client RRS feed

  • Question

  • Hi all,

    at this moment we are considering implementing App-V5 full infrastructure. We are at the designstage, so nothing is decided yet, let alone built in our production environment. The features of V5 were enough to halt the implementation of App-V 4.6 SP1 (full infrastructure).

    One of my collegues is testing with a setup, using a set of Riverbed Wan optimizers. To keep the tests as realisitic as possible they're placed in a live connection between two sites (one big, one small) in our production network. The big site is provisioned with local storage, the small site isn't. When it's testing time, the devices are enabled.

    Q1 : what's needed at minimum, to test App-V v5 http streaming to a client :

    I would like to test App-V5 streaming over the WAN optimizers, without the hassle of installing a management-/publishing-/database-server. I tested App-V 4.6 (http) streaming using just a simple IIS server, and a client. I was looking for an analogue setup, using v5 components (plus its respective requirements). I'm afraid I'm gonna need a little more than just IIS and a client. It will be a pain though, to have to install an SQL server, a management/publishing server just for this 15 minute test. Especially with all the security rules concerning setups in our production environment, and several actions having to be performed by different teams.

    Q2 : is there a need to even test v5, when v4.6 SP1 results are clear

    On the other hand : when the protocol hasn't changed, optimization will be in the same magnitude (about 40% reduction on first pass, speed dependant on local infrastructure on following passes). But has the http streaming process stayed the same ? Is there a penalty, when using the new fileformat (perhaps compressed by itself allready). 

    Thanks in advance,

    Erik Bakker

    Holland.

    Tuesday, June 4, 2013 12:05 PM

Answers

  • Q1: In theory you could use Powershell scripts on the client to do the 'publishing' part, telling the client tjhat it should download the package content from an HTTP source. However, since the App-V Management and Publishing Servers are IIS WebApplications as well I asume it might be affordable to install them (on the same box)

    Q2: I think that both, App-V 4 and 5 did not use an 'http download modules' of the operating system,. but have their own implementation to download http files. Therefor there might be minor differences there. Also, the new client does extract/decompress the downloaded content (.appv files are ZIP compressed), which some customers consider as 'quite slow'. Therefor, the actual download speed might become less important compared to the client device's disk+cpu performance for decompression. A 'real' test should take that into account, too.

     



    Falko

    Twitter @kirk_tn   |  Blog kirxblog   |  Web kirx.org

    Wednesday, June 5, 2013 8:04 AM
    Moderator
  • Q1: According the the Microsoft Supported configurations page, it seems as though that light weight streaming model is no more. You can acheive it by using App-V 4.6 SP2 for that branch office scenario whilst still using App-V 5.0 for your full streaming infrastructure. That is a supported configuration. You can read more about this co-existence scenario and all supported configurations: HERE

    Q2: HTTP\HTTPS to me seems the same. Like you have said it's the same protocol. When using SMB the performance appears to be drastically different. SMB gives you the benefit of using network resources in a more predictable fashion. I do not have any statistics to back up the statement about HTTP\HTTPS however, I have not performed any significant bench marking.

    May I add to your concerns about going over a WAN to a branch office and not having local storage. App-V is still pretty scalable. You do not, necessarily have to stream to all of your clients. You could use Group Policy to configure your branch office clients differently so they do not attempt to connect to the server, instead they operate in a standalone mode, however to acheive this you would need to deploy the MSI's generated during sequencing.

    Also, if you wanted, you could still set it up with SQL Express to test out. SQL Express 2008 has a 10GB limit I believe which should give you plenty to play around with. Perhaps you could discover that applications smaller than 200MB work fine streamed over the WAN or maybe of 100MB but everything else is noticably slow. In which case you could implement a standard to pre-cache applications larger than 100 or 200MB so once they are delivered to the users client device, they automatically begin to cache, so when they get in, in the morning they do not notice any performance impact


    PLEASE MARK ANY ANSWERS TO HELP OTHERS Blog: rorymon.com Twitter: @Rorymon


    • Edited by RorymonMVP Tuesday, June 4, 2013 1:24 PM Added more regarding different options
    • Proposed as answer by kirk_tnModerator Wednesday, June 5, 2013 8:04 AM
    • Marked as answer by Aaron.ParkerModerator Thursday, August 8, 2013 7:10 AM
    Tuesday, June 4, 2013 1:18 PM

All replies

  • Q1: According the the Microsoft Supported configurations page, it seems as though that light weight streaming model is no more. You can acheive it by using App-V 4.6 SP2 for that branch office scenario whilst still using App-V 5.0 for your full streaming infrastructure. That is a supported configuration. You can read more about this co-existence scenario and all supported configurations: HERE

    Q2: HTTP\HTTPS to me seems the same. Like you have said it's the same protocol. When using SMB the performance appears to be drastically different. SMB gives you the benefit of using network resources in a more predictable fashion. I do not have any statistics to back up the statement about HTTP\HTTPS however, I have not performed any significant bench marking.

    May I add to your concerns about going over a WAN to a branch office and not having local storage. App-V is still pretty scalable. You do not, necessarily have to stream to all of your clients. You could use Group Policy to configure your branch office clients differently so they do not attempt to connect to the server, instead they operate in a standalone mode, however to acheive this you would need to deploy the MSI's generated during sequencing.

    Also, if you wanted, you could still set it up with SQL Express to test out. SQL Express 2008 has a 10GB limit I believe which should give you plenty to play around with. Perhaps you could discover that applications smaller than 200MB work fine streamed over the WAN or maybe of 100MB but everything else is noticably slow. In which case you could implement a standard to pre-cache applications larger than 100 or 200MB so once they are delivered to the users client device, they automatically begin to cache, so when they get in, in the morning they do not notice any performance impact


    PLEASE MARK ANY ANSWERS TO HELP OTHERS Blog: rorymon.com Twitter: @Rorymon


    • Edited by RorymonMVP Tuesday, June 4, 2013 1:24 PM Added more regarding different options
    • Proposed as answer by kirk_tnModerator Wednesday, June 5, 2013 8:04 AM
    • Marked as answer by Aaron.ParkerModerator Thursday, August 8, 2013 7:10 AM
    Tuesday, June 4, 2013 1:18 PM
  • Q1: In theory you could use Powershell scripts on the client to do the 'publishing' part, telling the client tjhat it should download the package content from an HTTP source. However, since the App-V Management and Publishing Servers are IIS WebApplications as well I asume it might be affordable to install them (on the same box)

    Q2: I think that both, App-V 4 and 5 did not use an 'http download modules' of the operating system,. but have their own implementation to download http files. Therefor there might be minor differences there. Also, the new client does extract/decompress the downloaded content (.appv files are ZIP compressed), which some customers consider as 'quite slow'. Therefor, the actual download speed might become less important compared to the client device's disk+cpu performance for decompression. A 'real' test should take that into account, too.

     



    Falko

    Twitter @kirk_tn   |  Blog kirxblog   |  Web kirx.org

    Wednesday, June 5, 2013 8:04 AM
    Moderator
  • @ Rorymon

    @ Q1 : I as afraid it was so. I also read that deploying to a MS SQL Express computer is not supported (that won't mean it won't run offcourse). Guess I'll try that one in a sandbox environment first.

    @ Q2 : I'm not sure if we are going to utilize branch cache for our branch offices. Indeed it's not unthinkable we're gonna use some process to prepopulate the WAN optimizer cache. With the optimizer in place, effectively, only one pass across the line will be made per package. 

    Thank you for your answers !

    Regards, Erik.


    Thursday, June 6, 2013 11:14 AM
  • Q1: In theory you could use Powershell scripts on the client to do the 'publishing' part, telling the client tjhat it should download the package content from an HTTP source. However, since the App-V Management and Publishing Servers are IIS WebApplications as well I asume it might be affordable to install them (on the same box)

    Q2: I think that both, App-V 4 and 5 did not use an 'http download modules' of the operating system,. but have their own implementation to download http files. Therefor there might be minor differences there. Also, the new client does extract/decompress the downloaded content (.appv files are ZIP compressed), which some customers consider as 'quite slow'. Therefor, the actual download speed might become less important compared to the client device's disk+cpu performance for decompression. A 'real' test should take that into account, too.



    Falko

    Twitter @kirk_tn   |  Blog kirxblog   |  Web kirx.org

    Q1 : It's not the applications I'm worried about. It's the administrative hassle in my oragnisation to have the database installed in my production environment. It's the downside of ITIL in a nutshell :-(

    Q2 : When I was testing with 4.6 Sp1 I could see on the IIS side, standard HTTP get requests were issued (If I interpret your statement correctly). I think, transmitting a 'zipped' file over a WAN link, using compression, will gain some, but because less info is transmitted, the file will be transferred sooner. In the end, when the package is cached, no serious WAN traffic is generated.

    Thanks for your feedback,

    Erik.

    Thursday, June 6, 2013 11:33 AM
  • Sorry you are right. Express is not supported. Brain fart on my part! I remember the first time I tried to set it up, it balked because I tried SQL Express.

    PLEASE MARK ANY ANSWERS TO HELP OTHERS Blog: rorymon.com Twitter: @Rorymon

    Thursday, June 6, 2013 3:45 PM