virtual reality check - phase vi - impact office in vdi v1.01...as!! virtual!reality!check!...

Virtual Reality Check

Author(s) : Ryan Bijkerk, Jeroen van de Kamp & Ruben Spruijt

Version: 1.01

Date: June 2013

Project VRC: Phase VI Best practices and impact of Microsoft Office 2007, 2010 and 2013 in VDI

as


Phase VI: impact of Microsoft Office in VDI

Version 1.0 Page 1

as

©2013 PQR and Login Consultants, all rights reserved.

All rights reserved. Specifications are subject to change without notice. PQR and Login Consultants, the PQR and Login Consultants logo and its tagline Eenvoud in ICT are trademarks or registered trademarks of PQR and Login Consultants in the Netherlands and/or other countries. All other brands or products mentioned in this document are trademarks or registered trademarks of their respective holders and should be treated as such.

as



Version 1.0 Page 2

as

CONTENT

Summary 4

1. Introduction ............................................................................................................................ 5

2. Introduction to Project VRC .................................................................................................... 6

2.1 Project VRC objectives ...................................................................................................... 6 2.2 Intended audience ........................................................................................................... 7 2.3 Better together ................................................................................................................. 7 2.4 Contact ............................................................................................................................. 8

3. About the authors ................................................................................................................. 10

3.1 About Login Consultants ................................................................................................ 10 3.2 About PQR ...................................................................................................................... 10 3.3 Team members .............................................................................................................. 11

4. The Login VSI Benchmark ...................................................................................................... 13

4.1 Login VSI overview ......................................................................................................... 14 4.2 Login VSI 4.0 workload ................................................................................................... 15 4.3 What’s new in Login VSI 4.0 ........................................................................................... 15 4.4 VSImax v4 ....................................................................................................................... 19 4.5 Calculating VSImax ......................................................................................................... 20 4.6 Interpreting Project VRC results ..................................................................................... 23

5. The Project VRC Platform ...................................................................................................... 24

5.1 Physical design ............................................................................................................... 24 5.2 Logical design ................................................................................................................. 25 5.3 Test approach ................................................................................................................. 26

6. Office 2007 vs. Office 2010 vs. Office 2013 ........................................................................... 27

6.1 VSImax results ................................................................................................................ 27 6.2 ESXtop CPU results ......................................................................................................... 27 6.3 ESXtop Disk IO results ..................................................................................................... 29 6.4 Impact on memory ......................................................................................................... 30

7. Office 2013 Performance Tuning .......................................................................................... 33

7.1 VSImax results ................................................................................................................ 33 7.2 ESXtop CPU results ......................................................................................................... 34 7.3 ESXtop Disk IO results ..................................................................................................... 35

8. Win7 x86 Office 2010 x86 vs. Win 7 x64 Office 2010 x86 ..................................................... 36

8.1 VSImax results ................................................................................................................ 36

as



Version 1.0 Page 3

as

8.2 ESXtop CPU results ......................................................................................................... 37 8.3 ESXtop Disk IO results ..................................................................................................... 38 8.4 Impact on memory ......................................................................................................... 39 8.5 1vCPU ............................................................................................................................. 40

9. Win7 x64 Office 2010 x86 vs. Win7 x64 Office 2010 x64 ...................................................... 41

9.1 VSImax results ................................................................................................................ 41 9.2 ESXtop CPU results ......................................................................................................... 42 9.3 ESXtop Disk IO results ..................................................................................................... 43 9.4 Impact on memory ......................................................................................................... 44

10. Win7 x86 Office 2010 x86 vs. Win7 x64 Office 2010 x64 .................................................... 46

10.1 VSImax results .............................................................................................................. 46 10.2 ESXtop CPU results ....................................................................................................... 47 10.3 ESXtop Disk IO results .................................................................................................. 48 10.4 Impact on memory ....................................................................................................... 50

11. Office 2010 Indexing On vs. Off .......................................................................................... 51

11.1 VSImax results .............................................................................................................. 51 11.2 ESXtop CPU results ....................................................................................................... 52 11.3 ESXtop Disk IO results .................................................................................................. 53

as



Version 1.0 Page 4

as

SUMMARY

Microsoft Office is by far the most used application suite in the corporate environment. The Office suite is almost always deployed and used in virtual desktop infrastructures. But what is the performance impact of upgrading Microsoft Office?

This whitepaper focuses on the performance and capacity impact of the three most recent Office versions in VDI with Windows 7. Microsoft Office 2007, Office 2010 and Office 2013 are used with both x86 and x64 versions of Windows and Microsoft Office.

Comparing both Microsoft Office 2010 and 2013 with Office 2007 there is a negligible capacity impact of 1% with Office 2010, but there is a very substantial difference of 20% with Office 2013. As a result, upgrading to Office 2013 requires 20% more VDI capacity in comparison to Office 2007 and Office 2010.

Office 2013 will consistently use more CPU and much more memory. For instance, Office 2010 will consume 26% more memory than Office 2007. However, Office 2013 uses a rather momentous 272% (averaged) more memory on an application level.

Project VRC also tested possible performance optimizations for 2013 such as “animations off” and “hardware graphics acceleration off”. These optimizations did not make a positive performance difference.

Reviewing Office 2010 x86 and x64 running on Windows 7 x64 it is possible to conclude that the x64 bit architecture had no significant impact on VSImax v4, when CPU is the only limiting factor and enough memory and IO capacity is available. However, running x64 version of both Windows and Office will have substantial impact on storage IOPS and memory footprint. For instance, Microsoft Office 2010 x64 running on Windows 7 x64 will consume 32% more memory compared to Office 2010 x86 running on Windows 7 x86.

Also indexing (search) was reviewed and how it affects VDI capacity. Disabling indexing is considered a performance best practice, however, it is in highly appreciated feature by Office Users. If enough IO capacity is available, enabling indexing has only a 3% impact. If storage allows a potential 30% increase in write IO’s, it difficult to recommend disabling search, since it is such a critical feature to user acceptance.

Many organizations consider an upgrade to Office 2013 for its functional benefits. However, upgrading to Microsoft Office 2013 will have a significant user capacity impact within VDI. The impact of Office 2013 on CPU, memory and disk IO is considerably higher than Office 2007 and 2010. Currently, there are no obvious tuning best practices available to lower Office 2013’s performance impact. It is therefore highly recommended to evaluate the performance impact of Office 2013 in your own environment, before it is deployed.

as



Version 1.0 Page 5

as

1. INTRODUCTION

When virtual Windows desktops are hosted on shared hardware in the datacenter, its important to care about performance and capacity. Because the hardware is shared by users, and the available resources are limited, sizing and user experience become important topics. The capacity of the hardware (server and storage) is always limited. Ultimately, this can have a significant impact in the business case of desktop virtualization. Relatively small differences of 10 or 20 percent in desktop capacity can significantly increase required investments.

The desktop virtualization industry is getting more and more mature. We learned about impact of storage in VDI, learned how to tune the Windows guest OS and various hypervisors for performance and now know how to create scalable solutions. But there wasn’t a detailed reality check on the question: what is the impact on a performance level when you migrate to a newer Microsoft Office version.

For this reason Project VRC decided to investigate the impact of the different Microsoft Office versions on VDI. The following questions were asked:

• What are the performance differences between Office 2007, Office 2010 and Office 2013?

• Are there any performance optimizations possible for Office 2013? • What are the performance differences between x86 and x64 Windows and

Office architectures and how does it impact VDI sizing? • What is the performance impact of the indexing services?

Note: Frank Anderson from Citrix also researched the impact of Microsoft Office 2013. Frank created a blog post comparing Office 2010 x86 & Office 2013 x86 that can be found here: http://blogs.citrix.com/2013/03/27/microsoft-‐office-‐2013-‐impact-‐on-‐vdi-‐and-‐sbc-‐workloads/

as



Version 1.0 Page 6

as

2. INTRODUCTION TO PROJECT VRC

Welcome to “Project: Virtual Reality Check (VRC)”!

If you’re looking for independent advice and a ‘Reality Check’ in relation to virtualizing Remote Desktop Services and Desktop (VDI) workloads, if you are curious about the impact of different hypervisors and the performance differences with various hardware, if you’re searching for best practices for your virtual Desktops and if you’re curious about the performance impact of different Application Virtualization and Antivirus Solutions within VDI … the different Project VRC whitepapers are a must read!

PQR and Login Consultants started this unbiased and independent R&D project early 2009. The goal of Project VRC is to analyze the developments in the Application-‐ and Desktop Virtualization market and to objectively present the results. All together over 2000 tests have been carried out (Q2-‐2013).

In the haze of the extreme rate of innovation in the virtualization market and corresponding marketing promises this information is appreciated. Therefore we published our methods and conclusions in various whitepapers that can be downloaded from www.Projectvrc.com

2.1 PROJECT VRC OBJECTIVES The overall goal of Project VRC is to investigate, validate and give answers to the following questions and much more:

• What is the true impact of innovations on a hardware and hypervisor level? • Which performance optimization on the host and guest virtualization level can

be configured, and what is the impact of these settings on user density? • With the introduction of the latest hypervisor technologies, can we now

recommend running large-‐scale TS/CTX workloads on a virtualization platform? • How does a VDI infrastructure scale in comparison to Remote Desktop

Services? • How do various Microsoft Windows Client OS-‐es scale as a virtual desktop? • How do x86 and x64 TS platforms compare in scalability on bare metal and in

virtualized environments? • What is the best way to partition (memory and vCPU) the Virtual Machines on

the hypervisor host, to achieve the highest possible user density? • What is the impact of the latest and greatest hardware on (virtualized) terminal

servers and desktops? • What is the impact of adding extra ‘layers’ to a Remote Desktop Services or

(VDI) desktops, like application virtualization?

as



Version 1.0 Page 7

as

Project VRC is not finished, and probably never will be. We look forward to evaluate new innovations in the hypervisor arena, hardware level, Windows 8/Server2012 and impact in VDI and Remoting Protocols. Project VRC publishes their findings on www.projectvrc.com

2.2 INTENDED AUDIENCE This document is intended for IT managers, architects, (performance) analysts, system administrators and IT-‐pros in general who are responsible for and/or interested in designing, implementing and maintaining virtualized Remote Desktop Services and Virtual Desktop Infrastructures.

2.3 BETTER TOGETHER “...The two largest and most focused competitors in the Dutch Virtualization and Application Delivery market space are working together on Project: Virtual Reality Check...” PQR and Login Consultants started this joined-‐venture to share insights with the virtualization community with Project: Virtual Reality Check. There are several reasons for PQR and Login Consultants to execute this project together:

• The Project leaders, Ruben Sprit and Jeroen van de Kamp have known each other for a long time from the virtualization community and share the same passion for these technologies.

• Project VRC is a huge undertaking; PQR and Login Consultants individually do not have the resources, or time, to execute this project on their own. Thus is it logical to cooperate, share the workload and deliver the results together.

• Both organizations share the same technical vision, which is critically important in complicated projects like these.

as



Version 1.0 Page 8

as

2.4 CONTACT All information about Virtual Reality Check can be found at www.projectvrc.com. Contact details are:

PQR Login Consultants

Tel: +31 (0)30 6629729 Tel: +31 (0)20 3420280

E-‐mail: [email protected] E-‐mail: [email protected]

www.pqr.com www.loginconsultants.com

We try to provide accurate, clear, complete and usable information. We appreciate your feedback. If you have any comments, corrections, or suggestions for improvements of this document, we want to hear from you! Please send an email to Jeroen van de Kamp ([email protected]) or Ruben Spruijt ([email protected]). Include the product name and version number, and the title of the document in your message.

as



Version 1.0 Page 9

as

THIS DOCUMENT IS PROVIDED "AS IS"

WITHOUT WARRANTY OF ANY KIND

FOR REFERENCE PURPOSES ONLY

COPYRIGHT 2013, PQR & LOGIN CONSULTANTS

IT IS NOT ALLOWED TO (PARTIALLY) PUBLISH OR DISTRIBUTE CONTENT FROM THIS PAPER WITHOUT PRIOR APPROVAL

as



Version 1.0 Page 10

as

3. ABOUT THE AUTHORS

3.1 ABOUT LOGIN CONSULTANTS Innovations of the desktop infrastructure bring significant benefits in the areas of cost, security, and user experience. The challenge is to find the perfect balance between end-‐user freedom and manageability. Exponential growth of possibilities when it comes to devices, virtualization technologies, application models and cloud solutions make it difficult to keep an eye on the ball.

Login Consultants is an independent international IT service provider specialized in End User Computing. We help our clients in finding the optimal balance between IT control and end user flexibility. Our goal is create innovative solutions which simplifies future change. Our success with our customers is built on the quality of integration combined with a smart migration approach and the manageability of the solution after deployment.

Login Consultants has an experienced team with over 140 consultants in The Netherlands, Belgium and Germany. Our consultants have accreditations from Microsoft, Citrix and VMware, and are regularly invited to speak at national and international events. They are involved as experts in online and printed IT publications and actively participate in relevant technical blogs.

Login Consultants’ innovative drive is materialized in our own Solutions-‐lab. The specialists of Login Consultants continuously create innovative software solutions to support and enhance the quality of centralized desktop implementations. These efforts resulted in a suite of software tools adding value to the software solutions of amongst others Citrix, Microsoft and VMware. These freeware tools are used and appreciated by thousands of companies worldwide. The Solution-‐lab of Login Consultants has been the incubator for successful software solutions, like Flex Profiles, Login VSI and Automation Machine for Hosted Desktops.

3.2 ABOUT PQR PQR is a professional ICT infrastructure company focusing on the availability of data, applications and workspaces with optimized user experience in a secure and manageable way. PQR provides its customers innovative ICT solutions, from on-‐premise to cloud management, without processes getting complex. Simplicity in ICT, that’s what PQR stands for.

PQR has traceable references and a wide range of expertise in the field, proven by many of our high partner statuses and certifications. PQR is a Citrix Platinum Solution Advisor, HDS Tier 1 Platinum Partner, HP GOLD Preferred Partner, Microsoft Gold Partner, NetApp Star Partner, RES Platinum Reseller, VMware Premier Partner and

as



Version 1.0 Page 11

as

VMware Gold Authorized Consultant Partner. PQR’s approach is based on four main pillars:

• Data & System Availability • Application & Desktop Delivery • Secure Access & Secure Networking • Advanced IT Infrastructure & (Cloud) Management

PQR, founded in 1990, is headquartered in De Meern and has over 107 employees. In fiscal year 2011/2012 posted sales of € 94.9 million and a net after tax profit of € 4.6 million have been recorded. www.pqr.com

3.3 TEAM MEMBERS Sven Huisman, Consultant @ PQR

Sven Huisman (1977) studied Information Management in Utrecht. He started his career as system engineer and meanwhile he has over 10 years of experience in the IT business. He is one of PQR’s technical Consultants, focusing on Application and Desktop Delivery, hardware and software virtualization. Sven advises, designs, implements and migrates advanced ICT-‐infrastructures. He is a Citrix Certified Enterprise Administrator (CCEA), a Microsoft Certified Systems Engineer (MCSE) and a VMware Certified Professional (VCP). Sven is blogging about virtualization on VirtualFuture.info and was awarded as VMware vExpert. To contact Sven directly send an email to [email protected]. Follow Sven on twitter.

Ryan Bijkerk, Consultant @ Login VSI

Ryan Bijkerk (1989) started in the beginning of 2013 as a consultant at Login VSI. Ryan is involved in the development progress of Login VSI and coordinates a team of developers based on Scrum and Agile. Ryan also provides support to a large range of customers with a focus on Login VSI version 4. For Project VRC he is responsible for the test and the quality of these tests. Ryan also analyzes the results and discusses this with the Project VRC team and helps with writing the whitepapers. Ryan is blogging about his experience and solutions at Logitblog.com. To contact Ryan directly send an email to [email protected] or follow Ryan on twitter.

Jeroen van de Kamp, CTO @ Login Consultants

As Chief Technology Officer, Jeroen van de Kamp (1972) is responsible for defining and executing the technical strategy for Login Consultants. From the start, Jeroen has played a critical role in the technical growth and accreditation Login has accumulated over the years. He has developed several core solutions which allow Login Consultants to easily differentiate in the infrastructure consulting market.

as



Version 1.0 Page 12

as

Jeroen is also responsible for several well-‐known publications like the Flex Profile Kit, TCT templates & "The black hole effect". Because of his contribution to the technical community van de Kamp is recognized as a thought-‐leader in the application delivery industry and has become a residential speaker for seminars like BriForum, Citrix Solution Summit and many others. He is one of the 25 members worldwide who participate in the exclusive "Citrix Technology Professional" program. Jeroen is still engaged with strategic key accounts for Login Consultants, defining and realizing an all-‐encompassing strategy for the application, desktop and server delivery infrastructures. Previous to his position as CTO at Login Consultants Jeroen held positions as Infrastructure Architect at Login Consultants; IT Consultant at QFace ICT and IT specialist at ASG de Veer. To contact Jeroen send an email to [email protected] or follow him on twitter: @thejeroen.

Ruben Spruijt, CTO @ PQR

Ruben focuses primarily on Enterprise Mobility, Virtualization, Application and Desktop Delivery – tomorrow’s workspace. He is actively involved in determining PQR’s vision and strategy. Ruben is a Microsoft Most Valuable Professional (MVP), Citrix Technology Professional (CTP) and VMware vExpert and is the only European with these three virtualization awards. He gives customers advice and has them benefit from his expertise; he motivates his colleagues and writes blogs, articles and opinion pieces on a regular basis. During presentations in several national and international congresses, Ruben shares his thoughts and knowledge on application and desktop delivery, and on virtualization solutions. To contact Ruben at [email protected] or on twitter

as



Version 1.0 Page 13

as

4. THE LOGIN VSI BENCHMARK

For Project VRC, the industry standard Login Virtual Session Indexer (Login VSI 4.0) benchmarking solution was used. Login VSI offers a benchmarking methodology which calculates index numbers based on the amount of simultaneous sessions that can be run on a single physical machine, running either bare metal or virtualized operating systems. The commercial version of Login VSI offers different pre-‐packaged workloads and workload customization, including the addition of customer specific applications.

To keep the results of the Project VRC tests representative it is imperative that 100% identical tests are run on different types of systems. Therefore, Project VRC uses the standard medium Login VSI workload without any customization of the load scripts.

Login VSI is used by many other companies to review performance and publish white-‐papers including: AppSense, Atlantis Computing, Bitdefender, Cisco, Citrix, DataCore Software, Dell, EMC, ESG, Gridcentric, Hitachi, HP, McAfee, Microsoft and VMware. Many of these publications are listed here: http://www.loginvsi.com/white-‐papers

Login VSI focuses on how many users can run simultaneously on a system, while maintaining acceptable response times. Login VSI is comparable to investigating the maximum amount of seats on a bus or airplane using trial and error. This maximum number is called the “Virtual Session Index (VSImax v4)”.

On Virtual Desktop Infrastructure (VDI) and Server Based Computing (SBC) with Remote Desktop Services (RDS) workloads this gives very valid and useful information. This index simplifies comparisons and makes it possible to understand the true impact of configuration changes on hypervisor host or guest level.

Login VSI is a product independent benchmark which is specifically designed for VDI and SBC environments. With Login VSI it is possible to perform different load test scenarios:

• Test the maximum active session/desktop capacity (VSImax) of a single server • Perform a stability/soak/stress test for a longer period on a single server • Determine the maximum active session/desktop capacity (VSImax) of a group

of servers (a site/block/farm/enclosure) • Perform a stability/soak/stress test for a longer period on a group of servers (a

site/block/farm/enclosure) Login Virtual Session Indexer can be downloaded from: www.loginvsi.com

as



Version 1.0 Page 14

as

4.1 LOGIN VSI OVERVIEW A typical Login VSI 4.x environment consists of these components:

• Login VSI file share (VSIshare) § Login VSI binaries

• Management Console • Launcher • Analyzer • Session monitor • Data library

• An active directory infrastructure (Optional) § Login VSI user accounts § Login VSI group § A set of policies that make sure a test runs smooth

• Launcher(s) § Connection clients (e.g. Microsoft RDP, Citrix ICA or other client)

• Target § Microsoft Office

as



Version 1.0 Page 15

as

4.2 LOGIN VSI 4.0 WORKLOAD The standard Login VSI medium workload designed to run on 2vCPU’s per desktop VM.

• This workload emulates a medium knowledge worker using Office, IE, PDF and Java/FreeMind.

• Once a session has been started the workload will repeat (loop) every 48 minutes.

• The loop is divided in 4 segments, each consecutive Login VSI user logon will start a different segments. This ensures that all elements in the workload are equally used throughout the test.

• During each loop the response time is measured every 3-‐4 minutes.

• The medium workload opens up to 5 applications simultaneously.

• The keyboard type rate is 160 ms for each character.

• Approximately 2 minutes of idle time is included to simulate real-‐world users.

Each loop will open and use:

• Outlook, browse messages.

• Internet Explorer, browsing different webpages and a YouTube style video (480p movie trailer) is opened three times in every loop.

• Word, one instance to measure response time, one instance to review and edit a document.

• Doro PDF Printer & Acrobat Reader, the word document is printed and reviewed to PDF.

• Excel, a very large randomized sheet is opened.

• PowerPoint, a presentation is reviewed and edited.

• FreeMind, a Java based Mind Mapping application.

4.3 WHAT’S NEW IN LOGIN VSI 4.0 While the Project VRC phase I whitepaper is based on Login VSI 1.x, phase II is based on Login VSI 2.x, and the Project VRC phase III, IV and V are based on Login VSI 3.6. What’s new in version 4.0?:

Workload related changes

• Completely revised and up-‐to-‐date standard Login VSI workloads o More realistic user workload patterns o All workloads are now a 48 minutes loop (instead of 14 minutes)

as



Version 1.0 Page 16

as

o Each workload consists of 4 x 12 minute segments o Alternating initial segment for each session to ensure equal load distri-‐

bution o HTML5 video player instead of flash (flash player is still optional)

• Central data server for content in workload (instead of data in Program Files) o More realistic data set and data/file access in Login VSI workload o Larger document files in bigger Pro data pool: 1000 documents per type

(Login VSI Express contains 50 files per document type) o More and larger websites: each website contains 20 variants o Websites can run directly from share or through a IIS server o MP4 video library with all formats: 480p, 720p and 1080p o Login VSI v4 Pro library now +12GB (3.7: 300MB) o Multiple content servers can be configured for large scale tests

• Login VSI installation footprint in the desktop or server image minimized o No installation of Login VSI executables o No more performance tuning as part of setup o No more 300MB datalib in Program Files o (optional) Only installation of runtimes (e.g. Flash/Java/Adobe) o FreeMind runs as network/standalone app

• New and highly detailed logging format to simplify troubleshooting o All warnings and errors are centrally stored and shown o Workload debug mode logging for troubleshooting and customizing

workloads o Workload will create automatic screenshots of possible issues

• New workload editor to customize workloads o New meta language for maximum workload customization flexibility o Use standard workloads as template or start from scratch o Login VSI updates do not impact customization o It will be possible to download and share custom workloads o Management Console and Launcher related changes

Management Console and Launcher related changes

• New intuitive and workflow oriented Management Console o Easy, step-‐by-‐step setup and configuration

as



Version 1.0 Page 17

as

o Detailed launch scenario configuration: change logon rate overall or per launcher/server or CPU

o Connection configuration wizard that supports all brokers o Multi-‐language support in Management Console and workloads

• All settings can be centrally managed in the Management Console o Desktop pool redeployment/recomposes are no longer required for: o Login VSI settings changes o Login VSI updates o Workload customization and changes

• Centrally manage and start launchers (zero-‐touch) o No installation of Login VSI launcher software required o Automatic launcher start with RDP desktop sessions

• Fully customizable and exportable AD setup in PowerShell script format • New Direct Desktop Launch (DDL) Mode: start workloads without a remoting

client required [Pro only] o Minimum launching infrastructure required for testing o Start thousands of desktop sessions from a single launcher o Supported on Windows 7 and Windows 8 o Useful for comparing: o Storage configurations o Server or hypervisor changes o Changes on a Windows or application level

• It is now possible to configure multiple phases for one test o Simulate real-‐world production time logon patterns o Simulate logon storms o Perform soak tests (to evaluate long term stability)

• Benchmarking mode is specifically designed for test publications o Locks down configuration options o Simplifies setup and minimizes configuration mistakes o Only possible to run the official Login VSI medium workload o Mandates 48 minutes launch window for all sessions

• New dashboard with real-‐time test feedback in Management Console o Real-‐time progress feedback during test o General test overview o Launched and active sessions, elapsed time, time left

as



Version 1.0 Page 18

as

o Errors and warnings from workload and launchers o Real-‐time average logon time graph o Analyzer related changes

Analyzer related changes

• New more accurate “VSImax v4” o VSImax v4 is now a combination of 2 key metrics = VSImax and VSIbase o New calculation algorithm scales are optimized for high density envi-‐

ronments o New VSIbase phase is the pre-‐test Login VSI baseline response time

measurement and is executed before the Login VSI normal sessions are sampled

o Deviation in VSImax and VSIbase results are now less than 3% o No longer required to launch more sessions than VSImax

• All response time data is now logged in standard CSV format • Automated reporting options in the Login VSI analyzer will automatically gen-‐

erate test results overview o Test and workload settings o Login VSI response time graphs o Summary of test results o New and more VSImax metrics and results o Easily share results and discuss with others

as



Version 1.0 Page 19

as

4.4 VSIMAX V4 The philosophy behind Login VSI is different to conventional benchmarks. In general, most system benchmarks are steady state benchmarks. These benchmarks execute one or multiple processes, and the measured execution time is the outcome of the test. Simply put: the faster the execution time or the bigger the throughput, the faster the system is according to the benchmark.

Login VSI is different in approach. Login VSI is not primarily designed to be a steady state benchmark (however, if needed, Login VSI can act like one). Login VSI was designed to perform benchmarks for SBC or VDI workloads through system saturation. Login VSI loads the system with simulated user workloads using well-‐known desktop applications like Microsoft Office, Internet Explorer and Adobe PDF reader. By gradually increasing the amount of simulated users, the system will eventually be saturated. Once the system is saturated, the response time of the applications will increase significantly. This latency in application response times is a clear indication whether the system is (close to being) overloaded. As a result, by nearly overloading a system it is possible to find out what its true maximum user capacity is. After a test is performed, the response times can be analyzed to calculate the maximum active session/desktop capacity.

Within Login VSI this is calculated as VSImax. When the system is getting closer to its saturation point, response times will rise. When reviewing the average response time it will be clear the response times escalate at saturation point. With previous versions of Login VSI (Login VSI 3.x and older), if the system was not saturated during the test, it will not be able to calculate VSImax. This has changed with Login VSI 4.0.

This VSImax is the “Virtual Session Index (VSI)”. With Virtual Desktop Infrastructure (VDI) and Terminal Services (RDS) workloads this is valid and useful information. This index simplifies comparisons and makes it possible to understand the true impact of configuration changes on hypervisor host or guest level.

4.4.1 Server side response time measurements

It is important to understand why specific Login VSI design choices have been made. An important design choice is to execute the workload directly on the target system within the session instead of using remote sessions. The scripts simulating the workloads are performed by an engine that executes workload scripts on every target system, and are initiated at logon within the simulated user’s desktop session context.

An alternative to the Login VSI method would be to generate user actions client side through the remoting protocol. These methods are always specific to a product and vendor dependent. More importantly, some protocols simply do not have a method to script user actions client side. For Login VSI the choice has been made to execute the scripts completely server side. This is the only practical and platform independent

as



Version 1.0 Page 20

as

solution, for a benchmark like Login VSI. The relative overhead and footprint of a benchmark engine scripted in AutoIT is small enough (1-‐5% range) for Login VSI’s purposes.

4.5 CALCULATING VSIMAX V4 The simulated desktop workload is scripted in a 48 minute loop when a simulated Login VSI user is logged on, performing generic Office worker activities. After the loop is finished it will restart automatically. Within each loop the response times of twelve specific operations are measured in a regular interval: twelve times in within each loop. The response times of these six operations are used to determine VSImax v4. The six operations from which the response times are measured are: Starting “VSI Notepad” This operation is handled by the OS (loading and initiating VSINotepad.exe) and by the VSINotepad.exe itself through execution. This operation seems almost instant from an end-‐user’s point of view. Starting the “File Open” dialogue This operation is handled for a small part by Word and a large part by the operating system. The file open dialogue uses generic subsystems and interface components of the OS. The OS provides the contents of this dialogue. Starting the “Print” dialogue This operation is handled for a large part by the OS subsystems, as the print dialogue is provided by the OS. This dialogue loads the print-‐subsystem and the drivers of the se-‐lected printer. As a result, this dialogue is also dependent on disk performance. Compress the document into a zip file with 7-‐zip command line (2x) This operation is handled by the command line version of 7-‐zip. The compression will very briefly spike CPU and disk IO. This action is performed twice: once with no com-‐pression (IO intensive) and with high compression (CPU intensive) Starting Microsoft Word with a document This operation will measure the responsiveness of the Operating System and the file system. Microsoft Word is started and loaded into memory, also the new document is automatically loaded into Microsoft Word. When the disk IO is extensive or even satu-‐rated, this will impact the file open dialogue considerably. These measured operations within Login VSI do hit considerably different subsystems such as CPU (user and kernel), Memory, Disk, the OS in general, the application itself, print, GDI, etc. These operations are specifically short by nature. When such opera-‐

as



Version 1.0 Page 21

as

tions become consistently long: the system is saturated because of excessive queuing on any kind of resource. As a result, the average response times will then escalate. This effect is clearly visible to end-‐users. If such operations consistently consume multiple seconds the user will regard the system as slow and unresponsive.

4.5.1 VSImax v4 calculation

Once the test is finished, VSImax v4 can be calculated. Previous VSImax models (Classic and Dynamic) could not be calculated when the system was not fully saturated. In VSImax v4 this is not a requirement anymore.

The response times are very different per measurement type, for instance Zip with compression can be around 2800 ms, while the Zip action without compression can only take 75ms. These response time of these actions are weighted before they are added to the total. This ensures that each activity has an equal impact on the total response time. In comparison to previous VSImax models, this weighting much better represent system performance. All actions have very similar weight in the VSImax total, both in VSImax classic and dynamic the opening of word had far greater impact on the total than other activities.

The following actions are part of the VSImax v4 calculation and are weighted as followed:

• Start VSINotepad with large text file: 0.5 • Start File Open Dialogue: 1.25 • Start Print dialogue: 4 • Zip PST file without compression: 6 • Zip PST file with high compression: 0.175 • Start Word with new document from document pool: 15

This weighting is applied on the baseline and normal Login VSI response times. The average VSImax v4 baseline response time (also called VSIbase) in Login VSI 4.0 is calculated from the results recorded in the baseline phase. In total 30 VSI response time samples are takes by 5 baseline sessions. To ensure the VSIbase represents the optimal performance of the system, the highest 15 results are removed from the average calculation. To ensure no fluke low measurements are affecting the results unrealistically, the bottom 2 results are removed from the average VSIbase calculation. Over the remaining 13 VSI response time measurements the average VSImax baseline response time VSIbase is calculated. The VSImax v4 average response time in Login VSI 4.0 is calculated on the amount of active users that are logged on the system.

as



Version 1.0 Page 22

as

Always a 5 Login VSI response time samples are averaged + 40% of the amount of “active” sessions. For example, if the active sessions is 60, then latest 5 + 24 (=40% of 60) = 31 response time measurement are used for the average calculation.

To remove noise (accidental spikes) from the calculation, the top 5% and bottom 5% of the Login VSI response time samples are removed from the average calculation, with a minimum of 1 top and 1 bottom sample. As a result, with 60 active users, the last 31 Login VSI response time sample are taken. From those 31 samples the top 2 samples are removed and lowest 2 results are removed (5% of 31 = 1.55, rounded to 2). At 60 users the average is then calculated over the 27 remaining results. VSImax v4 is reached when the VSIbase + a 2600 ms latency threshold is not reached by the average Login VSI response time result.

Depending on the tested system, VSImax v4 response time can grow 2 -‐ 3x the baseline average. In end-‐user computing, a 3x increase in response time in comparison to the baseline is typically regarded as the maximum performance degradation to be considered acceptable.

In VSImax v4 the latency threshold is fixed to 2600ms, this allows better and fairer comparisons between two different systems, especially when they have different baseline results. Ultimately, in VSImax v4, the performance of the system is not decided by the total average response time, but by the latency is has under load. For all systems, this is now 2600ms (weighted).

The threshold for the total response time is: average weighted baseline phase response time + 2600ms. When the system has a weighted baseline response time average of 1500ms, the maximum average response time may not be greater than 4100ms (1500+2600). If the average baseline is 3000 the maximum average response time may not be greater than 5600ms (3000+2600). VSImax v4 is determined before the system has exceeded it threshold. For example, when the VSImax average on system has exceeded the Login VSI threshold at 80 users, the VSImax will be 79.

When the threshold is not exceeded by the average Login VSI response time during the test, VSImax is now considered the maximum amount of users that was launched. This approach is fundamentally different in comparison to previous VSImax methods, as is it was always required to saturate the system beyond VSImax threshold.

Lastly, VSImax v4 is now always reported with the average baseline Login VSI response time result. For example: “The VSImax v4 was 125 with a baseline of 1526ms”. This helps considerably in the comparison of systems and gives a more complete understanding of the system. The baseline performance helps to understand the best performance the system can give to an individual user. VSImax indicates what the total user capacity is for the system.

These two are not automatically connected and related: when a server with a very fast dual core CPU, running at 3.6 GHZ, is compared to a 10 core CPU, running at 2,26 GHZ,

as



Version 1.0 Page 23

as

the dual core machine will give and individual user better performance than the 10 core machine. This is indicated by the baseline Login VSI response time. The lower this score is, the better performance an individual user can expect.

However, the server with the slower 10 core CPU will easily have a larger capacity than the faster dual core system. This is indicated by VSImax v4, and the higher VSImax is, the larger overall user capacity can be expected.

With Login VSI 3.6 it was possible to choose between ‘VSImax Classic’ and 'VSImax Dynamic’. With Login VSI 4.0 a new VSImax method is introduced: VSImax v4. This methodology gives much better insight in system performance and scales to extremely large systems. ‘VSImax Classic’ and 'VSImax Dynamic’ are not suitable for large systems.

4.6 INTERPRETING PROJECT VRC RESULTS Project VRC uses the product independent Login VSI 4.0 benchmark to review, compare and analyze desktop workloads on VDI and SBC solutions. The primary purpose of VSImax is to allow sensible and easy to understand comparisons between different configurations.

The data found within Project VRC is therefore only representative for the VDI and SBC workloads. Project VRC results cannot and should never be translated into any other workloads like Exchange, SQL, IIS, Linux, Unix, Domain Controllers etc…

Also, the “VSImax” results (the maximum amount of Login VSI users), should never be directly interpreted as real-‐world results. The Login VSI workload has been made as realistic as possible, but it always remains a synthetic benchmark with a specific desktop workload. Real world VDI and SBC performance is completely dependent on the specific application set and how these applications are used. To include specific applications or customize the Login VSI workload, Login VSI Pro can be used.

as



Version 1.0 Page 24

as

5. THE PROJECT VRC PLATFORM

This chapter describes the architecture and components used by Project VRC, starting January 2013. Project VRC is using a Cisco UCS platform together with Hitachi Data Systems storage to perform VDI and SBC related performance tests. The results of these tests are published as whitepapers or blog posts on http://www.projectvrc.com.

5.1 PHYSICAL DESIGN Figure 1 shows the basic components and connectivity used to for the server, storage, and network. Four Cisco B200-‐M2 blades run VMware vSphere 5.1 and are hosting the backend infrastructure required for Login VSI and managing various hypervisors. Two Cisco B230-‐M2 can be provided with a hypervisor hosting virtual desktops or RDS servers or even with a bare metal RDS-‐server. Two Hitachi Data Systems AMS2100 are in place to provide the necessary storage for all the blades. With this hardware, two Login VSI tests can run simultaneously on dedicated hardware and storage.

Figure 1, Physical infrastructure

as



Version 1.0 Page 25

as

5.2 LOGICAL DESIGN As mentioned earlier, there are enough resources to run two (different) Login VSI tests simultaneously. Therefore, the hardware is split up in three logical environments, one for the general infrastructure components (VRC-‐Infra, colored green) and two for the Login VSI infrastructures (VRC-‐1 and VRC-‐2).

Figure 2, logical design

For a detailed overview please download the available Architecture and Hardware Setup whitepaper here. (registration required)

as



Version 1.0 Page 26

as

5.3 TEST APPROACH Unless mentioned otherwise, Project VRC consistently used these methodologies to perform their tests:

• All tests are executed on a virtual desktop environment using View 5.2.0 on vSphere 5.1.

• All sessions are launched from Windows 2008 r2 VM’s using direct RDP 7.1 connections.

• All test operations are fully automated: this ensures the consistency of the data.

• All tests are performed in a stateful desktop VM configuration

• Before each test is started, the server host and launcher infrastructure are completely restarted to ensure the test is not influenced by previous tests.

• In all tests the VMs are pre-‐booted, as a result the logon time frame is always 48 minutes.

• To ensure vSphere’s Transparent Page Sharing (TPS) can free memory resources, each test is initiated at least 30 minutes after the last VM has been started.

• All tests are performed at least five times and the average result is reported in this document (both ESXtop and VSImax v4).

• All VSImax v4 tests are performed with ESXTOP running in the background with a 30 second sample interval.

• VMware View Composer is used to create and deploy the VMs as linked clones.

Windows 7 was configured with 1GB memory with 2vCPU’s. Windows 7 has roughly 600-‐700MB free memory available, which is more than enough for the Login VSI workload. Windows 7 x64 was configured with 1.28GB of memory with 2vCPU’s.

The VM’s are fully optimized with the optimizations of the Project VRC whitepaper phase III. For a detailed overview please download the available Windows XP and Windows 7 whitepaper here. (registration required)

as



Version 1.0 Page 27

as

6. OFFICE 2007 VS. OFFICE 2010 VS. OFFICE 2013

This chapter describes the tests executed with the three most recent Microsoft Office versions. All tests are done on a Windows 7 x86 Professional virtual desktop with 2vCPU’s and 1024MB of memory. Unless stated otherwise, all tests are executed by logging on 150 Login VSI users within a 48-‐minute time frame.

6.1 VSIMAX V4 RESULTS Office 2007 is the reference (100%) for Office 2010 and 2013:

The X-‐axis shows the VSImax v4 in percentages. (higher is better)

Reviewing the VSImax v4 results in comparison to Office 2007 results in percentages (higher is better), the following observations are possible:

• There is a negligible difference with Office 2010 of 1%. • Office 2013 has a significant 20% impact on capacity.

6.2 ESXTOP CPU RESULTS The followings graphs are captured from ESXtop and are averaged result of all test runs (5 minimum).

0 20 40 60 80 100 120

Office 2013

Office 2010

Office 2007

VSImax v4 in %

as



Version 1.0 Page 28

as

The Y-‐axis shows the Util time of the CPU and the X-‐axis shows the amount of samples.

Reviewing the CPU graph in comparison to Office 2007 the following observations are possible:

• Office 2010 has small or no impact in comparison to Office 2007. • Office 2013 will consume around 20% more CPU.

as



Version 1.0 Page 29

as

6.3 ESXTOP DISK IO RESULTS

The Y-‐axis is Commands in seconds and the X-‐axis shows the amount of samples.

The Y-‐axis is Reads in seconds and the X-‐axis shows the amount of samples.

as



Version 1.0 Page 30

as

The Y-‐axis is Writes in seconds and the X-‐axis shows the amount of samples.

Reviewing the Disk IO graphs in comparison to Office 2007 the following observations are possible:

• Office 2010 has small impact on Write IO’s. • Office 2013 has a small impact on both Read & Write IO’s.

6.4 IMPACT ON MEMORY The total physical memory reserved by the Microsoft Office processes are collected after activity within the Microsoft Office application. Within each Microsoft Office application the same activity is reproduces for each Microsoft Office version. The total amount of mega bytes in memory are captured and used in the results.

as



Version 1.0 Page 31

as

The X-‐axis shows the total amount of mega bytes in memory. (lower is better)

Reviewing the result in comparison with Office 2007 (lower is better), the following observations are possible:

• Office 2010 Outlook & Word consume up to 30% more memory. • Office 2010 PowerPoint & Excel are roughly the same in memory consumption. • Office 2013 consumes a lot of memory for all applications.

The following graph is based on the total consumed memory per Microsoft Office version. The results are shown in percentages:

The X-‐axis shows percentage memory in use. (lower is better)

0 10 20 30 40 50 60

Word

Excel

PowerPoint

Outlook

Memory used in MB

Office 2007 Office 2010 Office 2013

0 50 100 150 200 250 300 350 400

Office 2013

Office 2010

Office 2007

Average memory reserved in %

as



Version 1.0 Page 32

as

Reviewing the result in comparison with Office 2007 (lower is better), the following observations are possible:

• Office 2010 consumes 26% more memory. • Office 2013 consumes 272% more memory.

as



Version 1.0 Page 33

as

7. OFFICE 2013 PERFORMANCE TUNING

This chapter reviews potential performance tuning options specific for Microsoft Office 2013. Two interesting settings were found that may have influence on the Office 2013 performance.

• Disable office animations This setting will disable all unnecessary Office animations. By default, anima-‐tion effects, such as fading between views, are enabled.

• Do not use hardware graphics acceleration This policy setting allows you to not use hardware graphics acceleration. If you enable this policy setting, hardware graphics acceleration will not be used. If you disable or do not configure this policy setting hardware graphics accelera-‐tion may be used.

7.1 VSIMAX V4 RESULTS Office 2013 with only the standard Virtual Desktop tuning (indexing disabled) represents 100%.


Reviewing the VSImax v4 results in comparison to Office 2013 results in percentages (higher is better), the following observations are possible:

• Performance tuning has a negligible impact on VSImax v4. • The differences are very small with a -‐1% and -‐2%.

0 20 40 60 80 100 120

Office 2013 Hardware Accelerazon Off

Office 2013 Animazons Off

Office 2013

VSImax v4 in %

as



Version 1.0 Page 34

as

7.2 ESXTOP CPU RESULTS Reviewing the CPU graphs it is clear that these settings made no significant change in CPU utilization.


as



Version 1.0 Page 35

as

7.3 ESXTOP DISK IO RESULTS Reviewing the Disk IO graphs it is clear that these settings made no significant change.


as



Version 1.0 Page 36

as

8. WIN7 X86 OFFICE 2010 X86 VS. WIN 7 X64 OFFICE 2010 X86 This chapter describes the difference between the bit architectures of Windows 7.

Windows 7 x86 has 2vCPU and 1024MB of memory. The Windows 7 x64 VM also has 2vCPU but 1280MB of memory to prevent excessive paging within Windows because of the higher memory footprint Windows x64 and Office x64 have.

8.1 VSIMAX V4 RESULTS


Reviewing the VSImax v4 results it is clear that from a session density point of view there is no major impact moving to Windows x64. However, there are differences from an IO and to lesser extend memory point of view. Since the Project VRC lab setup has more than enough memory and IO capacity, VSImax v4 is bound to CPU. Using 2vCPU’s both Windows architectures score identical.

0 20 40 60 80 100 120

Win 7 x64 Office 2010 x86


VSImax v4 in %

as



Version 1.0 Page 37

as

8.2 ESXTOP CPU RESULTS


Reviewing the CPU graph comparing Windows 7 x86 & Office 2010 x86 to Windows 7 x64 and Office 2010 x86 it is clear there is no significant performance impact to using Windows x64 with 2 vCPU’s.

as



Version 1.0 Page 38

as




as



Version 1.0 Page 39

as


Reviewing the Disk IO graphs in comparison to Office 2013 the following observations can be made:

• The Read IO is consistently higher, this is mostly related to the Windows 7 x64, which typically has a bigger disk footprint than Windows 7 x86.

8.4 IMPACT ON MEMORY The following graph is based on the memory consumed by each Office application.

The X-‐axis shows the amount of mega bytes used in memory. (lower is better)

0 5 10 15 20 25

Word

Excel

PowerPoint

Outlook

Memory used by Office Apps in MB's

Win7 x86 Office 2010 x86 Win7 x64 Office 2010 x86

as



Version 1.0 Page 40

as

The following graph is based on the total consumed memory per Office version.


On average Office 2010 x86 on Windows x64 only consumes 3% more memory on an application level than when it is running on Windows 7 x86.

8.5 1VCPU The same test was also performed with 1vCPU for each desktop VM. This clearly demonstrates that Office runs better with 2vCPU’s, especially with Windows x64.

Reviewing the x64 Windows VSImax v4 results in comparison to 32-‐bit Windows and Office 2010 with 1vCPU results in percentages (higher is better), the following observations can be made.

• The impact of running Office 2010 x86 on Windows x64 is now 19%. This can be related to the 1vCPU limitation. Windows and applications are clearly limited by the 1vCPU in Windows x64.

• A best practice is to use 2vCPU for Office Workloads.

0 20 40 60 80 100 120

Win7 x64 Office 2010 x86



0 20 40 60 80 100 120

Win7 x64 1vCPU Office 2010 x86

Win7 x86 1vCPU Office 2010 x86

VSImax v4 in %

as



Version 1.0 Page 41

as

9. WIN7 X64 OFFICE 2010 X86 VS. WIN7 X64 OFFICE 2010 X64 This chapter describes the difference between the bit architectures of Microsoft Office 2010 running on Windows 7 x64. Windows 7 x64 VM has 2vCPU and 1280MB of memory for both scenarios.



Reviewing the VSImax v4 results it is clear that moving from Office x86 to Office x64 on Windows 7 x64 has no significant impact on session capacity. The main bottleneck is CPU, and there is no significant change witnessed. However, the are differences on a memory and IO level.

The results will be different when the environment has limited IO capacity or is limited in memory for instance. Therefore it is always recommended to test and evaluate the impact in your own environment.

0 20 40 60 80 100 120



VSImax v4 in %

as



Version 1.0 Page 42

as



There are no changes in CPU utilization when Office 2010 x64 is used on Windows 7 x64 instead of Office 2010 x86.

as



Version 1.0 Page 43

as




as



Version 1.0 Page 44

as


Specifically, the read IO is higher and this can be attributed to the increased disk foot-‐print of Office 2010 x64 in comparison to Office 2010 x86.

9.4 IMPACT ON MEMORY

The X-‐axis shows the total amount of mega bytes in memory. (lower is better)

Office 2010 x64 on Windows 7 x64 consumes more memory which can be related to the higher bit architecture of 64-‐bit Office.

0 5 10 15 20 25 30

Word

Excel

PowerPoint

Outlook

Total physical memory reserved in kb


as



Version 1.0 Page 45

as



Reviewing the result (lower is better), the following observations is possible:

• In the average of the difference in memory consumptions is 28% • While there is no obvious performance benefit running a 64-‐bit Office version

(only with extreme Excel users), it is also hard to recommend using Office 64bit in practice.

0 20 40 60 80 100 120 140




as



Version 1.0 Page 46

as

10. WIN7 X86 OFFICE 2010 X86 VS. WIN7 X64 OFFICE 2010 X64 This chapter describes the difference between architectures of Windows 7 and Microsoft Office 2010. Windows 7 x86 VM has 2vCPU and 1024MB of memory and Windows 7 x64 VM has 2vCPU and 1280MB of memory.



When the main bottleneck is the CPU capacity, like it is in the Project VRC lab, moving from a full 32-‐bit Windows and Office to a full 64-‐bit does not have a significant impact on session density. However, there is a considerable impact on memory and disk usage, and this should always be considered. Therefore, it is highly recommend to test and evaluate this yourself in your own environment.

0 20 40 60 80 100 120



VSImax v4 in %

as



Version 1.0 Page 47

as



Reviewing the CPU graph it is clear that the CPU impact is negligible moving to full 64-‐bit Windows and Office.

as



Version 1.0 Page 48

as




as



Version 1.0 Page 49

as


Reviewing the Disk IO graphs in comparison to Windows 7 x86 Office 2010 x86 the following observations can be made:

• The Read IO is much higher and this can be attributed to the higher bit architec-‐ture of both Office 2010 and Windows 7

• This also affects the write IO but to a smaller extend.

as



Version 1.0 Page 50

as

10.4 IMPACT ON MEMORY

The X-‐axis shows -‐axis shows the total amount of mega bytes in memory. (lower is better)


Office 2010 x64 on Windows 7 x64 consumes 32% more memory in comparison to the 32-‐bit Windows and applications.

0 5 10 15 20 25 30

Word

Excel

PowerPoint

Outlook

Memory used in MB


0 20 40 60 80 100 120 140




as



Version 1.0 Page 51

as

11. OFFICE 2010 INDEXING ON VS. OFF

A performance best practice for VDI is to disable Windows indexing. However, this best practice is highly user-‐unfriendly as indexing is such an important feature for Office users. Disabling search will be immediately noticed by regular Office users. Although Project VRC disables search in all tests, it should not be considered a best practice for personal and stateful virtual desktops.

This chapter describes the difference between indexing on and off with Microsoft Office 2010. This was tested on Windows 7 x86 VM has 2vCPU and 1024MB of memory.



Reviewing the VSImax v4 results it is possible to conclude that enabling Indexing has a 3% impact on overall desktop density when enough memory and IO is available. Although it will impact IO considerably as witnessed in the ESXtop info, it is difficult to recommend disabling search for stateful and personal desktop VM’s.

0 20 40 60 80 100 120

Office 2010 Indexing On

Office 2010 Indexing Off

VSImax v4 in %

as



Version 1.0 Page 52

as



There is a small performance impact of indexing on the overall CPU utilization.

as



Version 1.0 Page 53

as




as



Version 1.0 Page 54

as


Reviewing the Disk IO graphs the following observations can be made:

• Indexing has a considerable impact on write IO’s, that can be related to the creation and maintenance of the index store.

• There is a small impact on read IO.

as



Version 1.0 Page 55

as

PQR B.V. Rijnzathe 7

3454 PV De Meern The Netherlands

Tel: +31 (0)30 6629729 Fax: +31 (0)30 6665905

E-‐mail: [email protected] www.PQR.com www.VirtuaLL.nl

Login Consultant Nederland B.V. De Entree 11-‐13

1101 BH Amsterdam The Netherlands

Tel: +31 (0)20 3420280 Fax: +31 (0)20 6975721

E-‐mail: [email protected] www.loginconsultants.com

virtual reality check - phase vi - impact office in vdi v1.01...as!! virtual!reality!check!...

Documents