Kaseya Performance

and

Best Practices

Guide

Authors: Jacques Eagle

…

Date: Thursday, April 29, 2010

Contents

Introduction

B.0 - The Basics

B.1 - Hot Fixes

B.2 64 bit versus 32 bit OS and SQL Server.

B.3 - System Requirements

B.4 - Browsers and workstations make a difference

M.0-Memory

How to monitor memory

M.1-Processes

M.2-64 Bit Operating System

M.3-32 Bit /3GB in the boot.ini

M.4 Memory Best Practices

C.0 - CPU

C.1 - Microsoft Reporting Services

C.2 - KaseyaMessageSys

C.3 – w3wp

C.4 - Kaseya Add-ons

C.5 - Larger number of files on servers and workstations

C.6 - Log Archive duration

C.7 – IIS Compression

N.0 - Network

N.1 – IIS Compression

V.0 - Virtualization with ESX

How to monitor resources under VMWare ESX

V.1-VMWare ESX Memory Configuration

V.2-VMWare ESX CPU Configuration Reservations

V.3-VMWare ESX CPU Configuration Limit

V.4-VMWare ESX VMWare tools up to date?

F.0 - Federation of Servers

A.0 - Add-On Performance Tips

A.1 - Service Desk

Performance and Best Practices Check List

B -The Basics

M-Performance Checklist for Memory

C-Performance Checklist for CPU

V-Performance Checklist for Virtualization with ESX

Appendix A – Monitor Sets

CPU

CPU – Reporting Services

CPU – Kaseya Messagesys

CPU – w3wp IIS Workpool Process

CPU – SQL Server Process

Introduction

If you are running Kaseya Version 5.x or previous versions and are close to maximizing your CPU, Networking and/or IO resources, don’t expect Version 6.x (K2) to run similarly on the same infrastructure. We hope this guide will help you with your planning on upgrading or a new install of Kaseya K2. Please remember that the Minimum Requirements on the Kaseya Support Site is based on an average. Every customer is different and your mileage will vary.

Kaseya is an enterprise application that requires specific hardware and software requirements in order to run effectively. These requirements include a database and IIS server(s), a network capable of handling agent traffic and a client platform and browser to present the user interface.

In addition, it is helpful to understand that every environment that is running Kaseya is different. There are many variables that will impact the performance of your Kaseya installation. The recommended requirements on our web site are a general guideline based on measures taken on multiple customer environments. The purpose of this document is to help you give your Kaseya Environment a Health Check by looking at various areas of performance and providing a checklist of items to review to implement best practices as it pertains to performance.

This document will go over the various areas of performance with recommendations of best practices where appropriate. Each of the sections are labeled in a way that they can be easily be referenced from the Performance Check List which is in the last section of this document. The sections covered in this guide are:

  • The Basics
  • Memory
  • CPU
  • Network
  • IO
  • Virtualization
  • Federation of Servers
  • Add-On Performance Tips
  • Service Desk
  • Performance Check List

B.0 - The Basics

B.1 - Hot Fixes

Make sure your up to date on hot fixes since performance related issues are addressed through this mechanism. Go to system, configure and make sure you have “Enable automatic check” checked. Also verify that you are current on hot fixes by looking at the “Last Hotfix” field. If not, click the “Get Lastest Hotfix” button. It is also a good idea to run the “Reapply Schema” link after hot fixes are applied since this may create any missing indexes on the database helping performance.

Some customers choose not to have this feature enabled. In this case, you should review this periodically and if you are experiencing performance issues, it’s best to apply all hot fixes before contacting support.

B.2 64 bit versus 32 bit OS and SQL Server.

Don’t use32 bit OS’s or SQL Server. It’s okay for test environments, but will not scale to support Kaseya.

B.3 - System Requirements

Did you review the minimum system requirements at the Kaseya support site?

Keep in mind that these requirements can vary based on many variables such as:

  • Number of audits
  • Number of patch scans
  • Number of KES scans
  • User/Sample scripts
  • Reporting
  • Log History
  • Agent History
  • Script distribution

It is therefore important for you to monitor your environment at all times and preferably with a Kaseya Agent. This way, you can monitor, track and alert when resources are constrained like CPU, Disk IO, Memory, SQL Server Locks, etc… Kaseya provides sample monitor sets as well as a NOC service that can monitor these for you. Please feel free to contact our NOC services for more details on this service. As we work with many clients, we constantly update our monitor sets to insure best practices in terms of monitoring the Kaseya solution.

B.4 - Browsers and workstations make a difference

The new features and functionality of the new Kaseya UI does require more resources in terms of Networking bandwidth and CPU on the clients workstation running the UI. The reason is that we are now using Java AJAX and JSON in order to render our pages. We have found that using Firefox over Internet Explorer provides better response times on the Kaseya UI and is highly recommended. Chrome appears to be the fastest; however, this browser is not supported at this time.

If you notice that the UI is slow, check to see how much CPU your workstation is utilizing during screen refreshes.If the CPU consistently hits 100%, your workstation may be under powered to render the pages. Also compare the CPU utilization between Firefox and Internet Explorer.

M.0-Memory

How to monitor memory

Memory can be monitored by using the resource monitor in Windows 2008. There are two key indicators that are important to memory and this is why they show on this panel. You should not see excessive Hard Faults/sec.Ideally, this number should be very low or even zero. If you see values in the double digits or more, you are running low on memory and disk swapping is occurring. This is bad.Also, make sure you are not above 85% on your Used Physical Memory. If you are, you should consider adding more RAM to your system.

M.1-Processes

You must have enough memory to support five of the most memory dependant processes in a single physical Kaseya Server environment. These processes are:

  • KaseyaMessageSys
  • W3wp (IIS Workpool)
  • Kserver
  • MS Sql Server
  • MS Sql Reporting Services

In Kaseya V6, the KaseyaMessageSys.exe is a new process that will allow Kaseya to scale with future versions and works closely with Microsoft Message Queuing. In addition to this, Version 6 also adds Microsoft Report Services.

KaseyaMessageSys can use 380 meg. of RAM for a small implementation of Kaseya (0-250 end points) to more than 1.2 Gig. Of RAM for larger installations (2500 or more end points).

In addition to KaseyaMessageSys, the new Kaseya UI requires more RAM from IIS (specifically, the IIS workpool process called w3wp). This process can use 250 Megabytes for a small implementation to 700 Megabytes or more for larger implementations.

Kaseya also utilizes Microsoft Reporting Services which will add additional memory pressure for your instances. Small instances can use 160-200 Megabytes while larger systems can use even more.

If you currently are running Kaseya V6, these memory requirements must be considered and addressed when you are ready to upgrade. Especially on systems that are running low on memory resources already.It is easy, therefore, to add another 800 Meg. to a small system just for the new Kaseya V6 release. For larger implementations, 2Gigabytes in additional RAM is not out of the question and highly recommended.

Also consider that Windows 2008 uses more RAM just to run itself. Typically, you should allocate at least 2Gig. Of RAM for the operating system alone.

M.2-64 Bit Operating System

Currently, it is highly recommended that even small installations of Kaseya Version 6 use 64bit Windows to address RAM over the 32 Bit limit of 4Gig. As shown above in section M.1, even a small installation of Kaseya can be impacted by new Kaseya and Windows 2008 requirements. In addition to the OS, SQL Server should be 64 Bit as well.

M.3-32 Bit /3GB in the boot.ini

Kaseya has seen that the /3GB switch in the boot.ini of 32 bit Windows causes excessive paging simply because more RAM is being allocated to applications and not to the Operating system. This switch is set in the boot.ini file and should be taken out. In its place, you should upgrade your Windows operating system to 64 bit or add additional memory to your existing 32 Bit environment and using the /PAE switch in its place. PAE is used by SQL Server (by enabling AWE) and can use the additional memory above the 32 Bit limit of 4GB. This feature does not work on 32 Bit Windows Standard Edition.

If you are limited to 32 bit systems and 4Gig of RAM, you should consider splitting the server into an application and database server. This will at least allow more RAM to both the database server and the application server.

M.4 Memory Best Practices

Make sure to monitor memory usage on the following processes to develop usage history and assess Memory requirements specific to your environment:

  • Sqlserver.exe
  • W3wp.exe
  • KaseyaMessageSys.exe
  • ReportingServicesService.exe
  • KServer.exe

C.0 - CPU

CPU utilization can vary based on many variables; however, with K2 you must plan to allocate more CPU than previous Kaseya Version 5 implementations for the same number of end points managed. This is due to the additional functionality of the back-end database and front-end. New processes, like Kaseya MessageSys and Microsoft Reporting Services will require CPU resources as well.

C.1 - Microsoft Reporting Services

Microsoft Reporting Services is new to K2 and utilizes more CPU and Memory to run reports than prior versions. If you schedule many reports to run, try not to schedule them during times that the server is also running audits and patch scans. Depending on your reporting load and data volume, you can use a whole core or more just for reporting. One way to track reporting CPU utilization is to use an Agent on your Kaseya server and create a monitor set for reporting services process. From here you can create graphs as shown below using Kaseya. In this example, there is little reporting, but when reporting does run, it can take 50% or more of a core. Please note that this is not 50% of total CPU on a server. For more information, please see the Appendix section for more detailed information and the XML to import this monitor set into your own environment.

C.2 - KaseyaMessageSys

This process will allow future versions of Kaseya to scale in terms of the number of endpoints. It works closely with other Kaseya modules and internal processes. In terms of CPU, this process may use between 5-10% of a core. If you install the Kaseya Service Desk, you may find this process using more CPU. The best practice is to monitor this process as well using the monitor set described in the appendix.

C.3 – w3wp

This is the IIS work pool process. It should be monitored since it is second to SQL server in terms of CPU resource consumption. This process will consume more resources based on the number of administrators on your system and is also impacted by the Service Desk Add-on.

C.4 - Kaseya Add-ons

Depending on the number of add-on products like KES, BUDR, User Profile and Service Desk, your requirements can vary appreciable in terms of memory, CPU, networking and IO.

C.4.1 – Kaseya Add-ons KES

In terms of CPU, KES and Service Desk will have an impact to your overall CPU utilization. For KES, in general, you should plan on an adding an additional 10% over the recommended CPU.

C.4.2 – Kaseya Add-ons Service Desk

The Service Desk will have an appreciable load on a server that is also running Kaseya. Currently, the following calculations should be done to estimate the additional CPU needed for single or dual server Kaseya implementation:

  • Application Server: Number of named users that will access the Service Desk * 15Mhz
  • Database Server: Number of named users that will access the Service Desk*35Mhz

Just add the two above if this is a single server install. For example, if you know you will have 50 users accessing the Service Desk Add-on, you should have the following additional CPU resources added to the Kaseya Minimum requirements:

  • Application Server: 50*15Mhz = 750Mhz
  • Database Server: 50*35Mhz = 1750Mhz

For a single Kaseya Server, just add them together. In this case, we come up with 2500Mhz. So a good rule of thumb is about 50 named users supported by one2.4Mhz Core of CPU.

C.5 - Larger number of files on servers and workstations

As servers and workstations become larger in size in terms of files, we must compare and store this detail on the Kaseya server. This in turn requires more space on the database and increases CPU to report and process this data especially during Audits.

C.6 - Log Archive duration

The longer you keep agent and monitor logs, the more resources it takes to run reporting and data mining. Try to keep the logs to a minimum.

C.7 – IIS Compression

Some companies may consider using IIS Compression to reduce bandwidth costs at hosting centers and improving performance on low latency/slower networks. The Kaseya application will benefit from compression on IIS6.0 and IIS7.0, but there is a CPU cost. Because of the various compression levels available, it is best to create a baseline on your CPU utilization and then slowly increase compression levels until a good balance is reached with existing CPU resources and improved page performance.

N.0 - Network

Just like CPU, networking will vary based on the number of scripts run, audit scan detail, Kaseya Add-on products, etc… It is important to monitor this carefully since Kaseya Version 6 will require more network bandwidth than previous versions of Kaseya. Where this is most evident is in the Kaseya UI.

The Kaseya UI now is based on Java AJAX and JSON. These technologies bring a feature rich experience to the end user. It is very much like a windows application versus a HTML based application. These features, however, require more networking bandwidth in order to run well.

N.1 – IIS Compression

IIS Compression can be set to help with overall performance of the Kaseya UI. Compression will help with performance from the networking perspective, but will affect the CPU utilization of IIS. Compression can be set to various levels.

To enable compression, install the Static and Dynamic Content Compression role services for IIS. Once these services are installed, you must enable them in IIS by opening the IIS Manager and clicking on the Compression icon.

Then check the Enable dynamic and static Content compression on the default website as well as the IIS Home. Please note that IIS 7.0 will stop compression if the server is starving for CPU. IIS 6.0 will not. Be sure to monitor CPU utilization on the server before and after this setting to insure the impact isn’t excessive.


V.0 - Virtualization with ESX

Customers who use ESX server should plan resources accordingly for Kaseya VM’s. In this section, we will cover best practices for Memory, IO and CPU. In some cases, you may be hosted by vendors using ESX. These recommendations should help in that situation as well.

How to monitor resources underVMWare ESX

VMWare ESX 4.0 now includes VMWare counters that help you determine the configuration and performance of your VM under ESX. These counters are installed as part of the installation of VMWare Tools for the Virtual Machine (VM). ESX 3.5 doesn’t have these counters installed as part of VMWare tools. Access to the counters is shown below. Just click on All Programs -> VMware -> WMware Tools -> start VM Statistics Logging.

From here you will see two counters related to VMWare. VM Memory and VM Processor. Each of these is used for the sections below on best practices for a VMware installation in terms of Memory and CPU.

V.1-VMWare ESX Memory Configuration

VMware allows multiple Virtual Machines to share resources such as memory and CPU. Under certain conditions, memory can be over allocated on the ESX server, but the VM will not indicate this through its own resource monitoring. To the VM, it may think it has plenty of memory. The issue is that the ESX server may be paging memory to its own paging file impacting the performance of the underlying VM running Kaseya. To keep this from happening, insure that Virtual Machines that are running Kaseya have enough reserved memory allocated to the VM. Typically, you should reserve at a minimum 2gig of RAM for small installations and in larger, you should do 50% or more the VM’s memory. If the servers are split as an application server and a database server, you must still reserve memory to both for best performance.