Optimizing Sage 300 & Sage Estimating (Pervasive) for use in Published Environments (Citrix, Terminal Services, Cloud Computing, etc...).

This discussion is geared at compiling documentation on any preferred methods, settings, or recommendations that will allow users to
optimize the use of Sage 300, and Sage Estimating Pervasive in a published environment. 

I'm looking for any suggestions, Ideals, do's or don'ts that you may have come across while setting up Sage 300 in a Published environment.  

Note:  Please note that making any of these changes to your system are done at your own risk.  If you have any questions or concerns regarding these posts please feel free to post them here or contact your IT solution for more information. 

  • Recommendations from Microsoft on optimizing Server 2008 are found here @http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv.mspx

     

    Applications Tuning for Terminal Server:

    Most of the CPU usage on a Terminal Server system is driven by applications. Desktop applications are usually optimized toward responsiveness with the goal of minimizing how long it takes an application to respond to a user request. However, in a server environment it is equally important to minimize the total amount of CPU that is used to complete an action to avoid adversely affecting other sessions.

    Consider the following suggestions when you configure applications to be used on a Terminal Server system:

    •        Minimize background/Idle loop processing.

    Typical examples are disabling background grammar/spell checking, data indexing for search, and background saves.

    •        Minimize how often an application polls to do a state check or update.

    Disabling such behaviors or increasing the interval between polling iterations and timer firing significantly benefits CPU usage because the CPU effect of such activities is quickly amplified for many active sessions. Typical examples are connection status icons and status bar information updates.

    •        Minimize resource contention between applications by reducing their synchronization frequency with that resource.

    Examples of such resources include registry keys and configuration files. Examples of such application components and features are status indicator (like shell notifications), background indexing or change monitoring, and offline synchronization.

    •        Disable unnecessary processes that are registered to be started at user logon or session startup.

    These processes can significantly contribute to the CPU cost of creating a new session for the user, which generally is a CPU-intensive process and can be very expensive in morning scenarios. Use MsConfig.exe or MsInfo32.exe to obtain a list of processes that are started at user logon.

    •        When possible, avoid multimedia application components for Terminal Server deployments.

    Video playback causes high bandwidth usage for the Terminal Server connection, and audio playback causes high bandwidth usage on the audio redirection channel. Also, multimedia processing (encoding and decoding, mixing, and so on) has a significant CPU usage cost. 

    For memory consumption, consider the following suggestions:

    •        Verify that dlls that applications load are not relocated at load.

    If dlls are relocated, it is impossible to share their code across sessions, which significantly increases the footprint of a session. This is one of the most common memory-related performance problems in Terminal Server.

    •        For common language runtime (CLR) applications, use Native Image Generator (Ngen.exe) to increase page sharing and reduce CPU overhead.

    When possible, apply similar techniques to other similar execution engines.

     

    Terminal Server Tuning Parameters.

     

    Pagefile

    Insufficient pagefile can cause memory allocation failures either in applications or system components. A general guideline is that the combined size of the pagefiles should be two to three times larger than the physical memory size. You can use the Memory\Committed Bytes performance counter to monitor how much committed virtual memory is on the system. When the value of this counter reaches close to the total combined size of physical memory and pagefiles, memory allocation begins to fail. Because of significant disk I/O activity that pagefile access generates, consider using a dedicated storage device for the pagefile, ideally a high-performance one such as a RAID array.

     

    Antivirus and Antispyware

    Installing antivirus and antispyware software on a Terminal Server greatly affects overall system performance, especially on CPU usage. We highly recommend that you exclude from the active monitoring list all the folders that hold temporary files, especially those that services and other system components generate. Generally, antispyware software has a much more significant performance effect than antivirus software does and should be installed only when it is necessary.

     

    Task Scheduler

    Task Scheduler (which can be accessed under All Programs > Accessories > System Tools) lets you examine the list of tasks that are scheduled for different events. For Terminal Server, it is useful to focus specifically on the tasks that are configured to run on idle, at user logon, or on session connect and disconnect. Because of the specifics assumptions of the deployment, many of these tasks might be unnecessary.

     

    Desktop Notification Icons

    Notification icons on the Desktop can have fairly expensive refreshing mechanisms. You can use Customize Notifications Icons to examine the list of notifications that are available in the system. Generally, it is best to disable unnecessary notifications by either removing the component that registers them from the startup list or by changing the configuration on applications and system components to disable them.

    You can implement the following tuning parameters by opening the MMC snap-in for Group Policy (gpedit.smc) and making the respective changes under Computer Configuration > Administrative Templates > Windows Components > Terminal Services > Terminal Server:

    •        Color depth.

    Color depth can be adjusted under Remote Session Environment > Limit Maximum Color Depth with possible values of 8, 15, 16, and 32 bit. The default value is 16 bit, and increasing the bit depth increases memory and bandwidth consumption. Or, the color depth can be adjusted from TSConfig.exe by opening the Properties dialog box for a specific connection and, on the Client Setting tab, changing the selected value in the drop-down box under Color Depth. The Limit Maximum Color Depth check box must be selected.

    •        Remote Desktop Protocol compression.

    Remote Desktop Protocol (RDP) compression can be configured under Remote Session Environment > Set compression algorithm for RDP data. Three values are possible:

    •        Optimized to use less memory is the configuration that matches the default Windows Server 2003 configuration. This uses the least amount of memory per session but has the lowest compression ratio and therefore the highest bandwidth consumption.

    •        Balances memory and network bandwidth is the default setting for Windows Server 2008. This has reduced bandwidth consumption while marginally increasing memory consumption (approximately 200 KB per session).

    •        Optimized to use less network bandwidth further reduces network bandwidth usage at a cost of approximately 2 MB per session. This memory is allocated in the kernel virtual address space and can have a significant effect on 32-bit processor-based systems that are running a fairly large number of users. Because 64-bit systems do not have these issues, this setting is recommended if the additional memory cost is considered acceptable. If you want to use this setting, you should assess the maximum number of sessions and test to that level with this setting before placing a server in production.

    •        Device redirection.

    Device redirection can be configured under Device and Resource Redirection. Or, it can be configured through TSConfig by opening the properties for a specific connection such as RDP-Tcp and, on the Client Settings tab, changing Redirection settings.

    Generally, device redirection increases how much network bandwidth Terminal Server connections use because data is exchanged between devices on the client machines and processes that are running in the server session. The extent of the increase is a function of the nature of frequency of operations that are performed by the applications that are running on the server against the redirected devices.

    Printer redirection and Plug and Play device redirection also increase logon CPU usage. You can redirect printers in two ways:

    •        Matching printer driver-based redirection when a driver for the printer must be installed on the server. Earlier releases of Windows Server used this method.

    •        Easy Print printer driver redirection, which is a new method in Windows Server 2008 that uses a common printer driver for all printers.

    We recommend the Easy Print method because it causes less CPU usage for printer installation at connection time. The matching driver method causes increased CPU usage because it requires the spooler service to load different drivers. For bandwidth usage, the Easy Print method causes slightly increased network bandwidth usage, but not significant enough to offset the other performance, manageability, and reliability benefits.

    Audio redirection is disabled by default because using it causes a steady stream of network traffic. Audio redirection also enables users to run multimedia applications that typically have high CPU consumption.

    Client Experience Settings

    The Terminal Server Client provides control over a range of settings that influence network bandwidth performance for the Terminal Server connection. You can access them either through the Terminal Server Client user interface on the Experience tab or as settings in the RDP file:

    •        Disable wallpaper (RDP file setting: disable wallpaper:i:0) suppresses the display of desktop wallpaper on redirected connections. It can significantly reduce bandwidth usage if desktop wallpaper consists of an image or other content with significant drawing cost.

    •        Font smoothing (RDP file setting: allow font smoothing:i:0) controls ClearType font rendering support. Although this improves the rendering quality for fonts when it is enabled, it does affect network bandwidth consumption significantly (generally more than 400 percent).

    •        Desktop composition is supported only for a remote session to Windows Vista and has no relevance for server systems.

    •        Show contents of windows while dragging (RDP file setting: disable full window drag:i:1), when it is disabled, reduces bandwidth by displaying only the window frame instead of all the contents when dragged.

    •        Menu and window animation (represented by two distinct RDP file settings: disable menu anims:i:1 and disable cursor setting:i:1), when it is disabled, reduces bandwidth by disabling animation on menus (such as fading) and cursors.

    •        Themes (RDP file setting: disable themes:i:1), when it is disabled, reduces bandwidth by simplifying theme drawings that use the classic theme.

    •        Bitmap cache (RDP file setting: bitmapcachepersistenable:i:1), when it is enabled, creates a client-side cache of bitmaps that are rendered in the session. It is a significant improvement on bandwidth usage and should always be enabled (except for security considerations).

    Desktop Size

    Desktop size for remote sessions can be controlled either through the TS Client user interface (on the Display tab under Remote desktop size settings) or the RDP file (desktopwidth:i:1152 and desktopheight:i:864). The larger the desktop size, the greater the memory and bandwidth consumption that is associated with that session. The current maximum desktop size that a server accepts is 4096 x 2048.

    Windows System Resource Manager

    Windows System Resource Manager (WSRM) is an optional component that is available in Windows Server 2008 that now supports an “equal per session” built-in policy that keeps CPU usage equally distributed among all active sessions on the system. Although enabling WSRM adds some CPU usage overhead to the system, we recommend that you enable it because it helps limit the effect that high CPU usage in one session has on the other sessions on the system. This helps improve user experience and also lets you run more users on the system because of a reduced need for a large cushion in CPU capacity to 0020 accommodate random CPU usage spikes.

  • in reply to jchristo

    From a support stand point here are some of the things that I've come across that would also be recommend when publishing Sage 300 Accounting or Estimating.  (Note: some of these suggestions may not be practical in all cases).

    - Set a very liberal reboot schedule.  (At least once a week if not more.)

    - Keep the application Data and the install on separate physical drives. (Accounting server: the accounting company data as well).

    - Limit the number of processes/services that can run on the terminal server.

    - Load balance the machines based on department or processes inside of Timberline. - Do not install any type of Active threat protection on the Terminal servers.  (Harden the server in other ways to prevent penetration).

    - Set Anti-Virus exclusions and do not scan the Server(s) during the day while it is use. (KB116381)

    - Give your users the needed permissions to run Sage 300. (KB244)

    - If running in virtual environments store your Virtual Machine files and virtual drive files on separate physical disks. 

    - Map Network Printers instead of mapping sessionized printers.

    - Do not run any type in incremental backup while people are using or are logged into Sage 300.

    - If there is only one terminal server and you are trying to optimize speed consider storing the data on the terminal server itself.

    - Install the same licensing type of pervasive database as is on the server. (Meaning NT Engine 64bit - NT Engine 64bit.  If possible especially if the terminal server is virtual server) .  See http://cs.pervasive.com/forums/p/12743/43659.aspx

    - Disable engine cache in Pervasive only if Property Management is not being used. (Which will allow you to see individual users who are logged in using the Pervasive Monitor Utility (W3monv75.exe) on a Terminal Server.  Contact support for consideration.

    - Do not use FQDN’s (Fully Qualified Domain Names) for drive mappings.  Just the computers name.

    - If the Terminal Servers are Virtual increase your VM backbone speed.

  • in reply to jchristo

    - Enable back to minimal state.  

    By default 'Back to minimal state' is not enabled.  This setting gives the Microkernal engine permission to allocate and hold onto memory not freeing it as it is finished.  The problem is that on a terminal server memory has to be distributed amongst the number of users, the operating system, other applications & services, and the database engine.  Considering that the operating system requires a certain amount of memory you don't wont your users or the operating system fighting the database engine for memory.  Especially since memory is cheaper then it used to be and 64 bit Operating systems allow for more memory to be allocated to each user.  To disable back to minimal state open up Pervasive Control Center -> Click Configure Local Engine -> Select Memory Usage > Check Back to Minimal State.  You can do this on both the server and the workstations or just the terminal servers.

  • in reply to jchristo

    Great information!!!

    Couple of things from my experience to add\comment on

    - Reboot schedule

    Add the Sage 300 CRE file server to the reboot schedule, it is usually more beneficial to reboot it as that will free up any oplocks that are common in server/terminal server environments.

    msdn.microsoft.com/.../aa365433(v=vs.85).aspx

    We used to disable this feature quite a bit but Windows 2008 seems to handle it better.

    - Enable back to minimal state

    This applies to machines that are serving data for the most part, if the terminal server is being used as a server this could apply (although I wouldn't recommend it) but for a terminal server being a used as a Sage 300 CRE client it would not need to be changed.

    If you wanted to control memory allocation of the workgroup or server engine on the terminal server you could go into configure microkernel engine settings\performance tuning and change the L1 cache (cache allocation Size and the dynamic L2 Cache (Max microkernel memory usage) If you hover over each of these you can see the differences. Again these apply to an engine serving data so changing them to lower values will have little effect on client performance but could free up memory for other processes.

    Each installation has a server engine and client engine (microkernel router) on a Sage 300 CRE client the microkernel router memory resources is used for client side caching.  If CAC is turned off the microkernel router doesn't use much resources on a client.

    Old article in Pervasive KB, still applies. 

    http://support.pervasive.com/t5/Database-Products-Knowledge-base/lt-FONT-face-Arial-color-0000ff-size-2-gt-What-are-the-Allocate/ta-p/10897

     

    - Page file

    The information above is good guidelines except that I would recommend setting it let windows manage. If for whatever reason the page file fails to allocate it on the file server it can cause significant slowdowns and lags. On the client (terminal server) it can cause some interesting errors because cache is no longer correct.

    - Printers

    In addition to a PCL 5e driver when available, I would recommend setting the spool settings to print after last page is spooled and Print Processor to RAW where applicable.

    - Single server solution.

    When possible is a great solution for smaller Sage 300 CRE user base. The oplocks do not exist in this setup and performance is increased because there is no data over the network, the downside is server security and scalibility is limited.

    - Encourage users to log off rather than disconnect.

    It is not a good idea to disconnect and reconnect over an extended period of time, this can cause caching and performance issues. Counter intuitive to that it is not good to automatically close inactive disconnected sessions which can lead to lose of work and files locks.

     

  • in reply to Bob Moton

    Thanks for the feed back I'll update that.  I spoke with Karen and she suggested that there really isn't an issue with PCL 6 so I removed that part.  I'll add it back if it's still an issue.

  • in reply to jchristo

    Hi, sorry to hijack the thread a little, but it is Citrix related.  Does anyone have any installation guidelines for Sage 300 CRE for a Citrix environment?  I know it's not officially supported, so wondering if anyone has some notes from their experiences.....  Thanks.  -m

  • in reply to invisik

    Invisik sorry for belated response, but as far as installation guidelines that would all be covered in the user guide.pdf if your installing 13.1 or waiting for this summers release of 14.1.  Depending upon whether you are planning to use your Citrix box as a client or an accounting server.  

    If you are just using the citrix box or boxes as a client then you would install it as a normal client install.  There are no special configurations (for the install) that would be different from a normal client install.  There is one thing that I personally would recommend and that is depending upon your setup.  If the Citrix boxes are clients and they are 2008 or higher 64-bit vm's.  I would recommend manually installing the 64 bit pervasive database engine server which can be found in the prerequisites folder in the wininst folder or the server download.  It's location is for the server download is

    %download location%\Install\Prerequisites\Pervasive PSQL v10 Server Edition (x64).  

    client install

    \\serversname\\Timberline Office\9.5\Accounting\Wininst\Prerequisites\Pervasive PSQL v11 Server Edition (x64)  There is a reason for this I will try and find the pervasive kb and include it in a few moments.

    It's the same install of pervasive from either location.  Install that first and then run the installer from the \\serversname\\Timberline Office\9.5\Accounting\Wininst\Install.exe.  After the install two services will be installed the pervasive relational and pervasive transactional service.  Create a administrative service account that you can run those services as the account should have full control over locally and on the accounting server.

    Outside of that it's just another client. 

    Regards

    Jon

  • in reply to jchristo

    Hi, thanks for this info.

    Our Citrix server is to be the Timberline Server and Timberline Client.  After installing the Timberline Server components, I didn't run the Timberline Client as TS-Main was already present. The server is 2008 R2 64-bit.  

    As the Timberline Server is basically Pervasive SQL, I don't see why they couldn't co-exist on the same single server.

    Did you have to set any file permissions to get the Timberline Client to work properly?

    Thanks again....

    -m

    PS: I started this thread for an error we're regularly getting in TS-Main, if you want to give me your thoughts:

     

    http://sagecity.na.sage.com/support_communities/sage_construction_and_real_estate/f/9/t/75560.aspx