Production Hosting Guide

Once configured correctly, the Website Accelerator is designed to run continuously in a production environment without intervention. In summary form, the key things to ensure when moving to production are:

Install the Website Accelerator + an appropriate license on each server and site required
Import the configuration from a test environment, or customise the config in place
Specify an on-disk cache path in the wax.config file (and any load balanced node settings)
Set run-mode to Production in the WAX Configuration tool to hide the Aptimize logo
Ensure that the on-disk site content and wax.config are identical on all servers in a cluster

Below are the recommendations in detail for configuring the Website Accelerator for production hosting.

Moving from test to production

It is assumed that the typical installation involves the process of testing the set of optimizations chosen in a development, test or other pre-production environment. It is also assumed that the move to production will be done either in an outage window, or server by server by removing each machine in turn from a cluster.

When the settings are configured as desired in the test environment and you are ready to move to production, you can choose Save Config from the File menu in the Website Accelerator Config tool. Choose the location and name to save the file as, and then move this file to somewhere accessible from your production hosting environment.

On the production web server, install the Website Accelerator if you have not already done so. From the Start menu find the Aptimize programs group and run the Configuration tool. Select the correct website from the list on the left and then select Load Configuration from the File menu.

Once loaded, you should click the Configure button, and then from the Run Mode tab switch from Development to Production. This will hide the Aptimize logo that appears in the top left of every page, and ensure that only important errors are logged to the event log.

To do this you must have a valid license installed, which can be achieved by either clicking Install License if you already have a license file, or by clicking Get License.

Multi-server / load-balanced configuration

When running on a load-balanced site, the Website Accelerator must be installed on each server, and on each site that it is to run on. The configuration file for the site must also be present on each server, along with the appropriate license. Licenses can be installed on each server by repeating the process for each machine as above, or by copying the license files directly into the site root directory and recycling the application pool for the site.

Once the Website Accelerator is installed on a server and site, it is possible to synchronize the wax.config configuration file using the WAX Configuration Tool – from the Options menu, select Cluster Manager.

Specifying a cache path

To allow the Website Accelerator cache to survive the IIS worker process being recycled, or to run in a load-balanced configuration, an on-disk cache path must be specified.

There are 3 options for using a disk cache:

Isolated local cache

This mode is suitable for single server installations, or load balanced environments where server affinity can be assured. Any local disk path can be specified in the cachePath attribute of the wax.config file, and the Website Accelerator will write it's resources to this location. The user identity of the application pool the site runs as must be granted read/write/modify permissions to this directory.

<wax:configuration cachePath="C:\WaxCache">
</wax:configuration>

Shared remote cache

This mode is appropriate for single or load balanced environments, where cache redundancy is not essential (e.g. where you have a single database server, and web server nodes exist only for performance rather than redundancy). Any UNC based path can be used, as long as the user identity of the application pool as read/write/modify permissions to the remote file system and the remote share.

<wax:configuration cachePath="\\192.168.0.15\WaxCache">
</wax:configuration>

Replicated local cache

This mode suits a cluster where redundancy is important. Each web server node must be configured with a local cache, into which resources are replicated from other nodes in the cluster as required. The example below shows a configuration where all nodes use a path called C:\WaxCache\SiteX to store their local copy of cached resources, and the cluster definition that allows the Website Accelerator to find remote nodes and replicate cache content as required.

<wax:configuration cachePath="C:\WaxCache\SiteX">
  <cluster cacheMode="Replicated" networkPath="WaxCache\SiteX" >
    <node hostName="Foo" />
    <node hostName="Bar" />
  </cluster>
</wax:configuration>

Note: the cachePath attribute is shown on it's own above - a real configuration file would have many other attributes already present, so you should add cachePath in addition to these other existing attributes.

The function of each of these settings is as follows:

cacheMode: May be "Shared" or "Replicated". When the cluster element is not present, Shared is assumed.

networkPath: This is the share name plus any child path beneath the share. The remote server name / IP address should not be included in this setting as this is combined with the hostName of the node.

hostName: Specifies the DNS name, either short or fully qualified, of each host node in the cluster. This name will be used with the networkPath to form the full path to find remote resources.

zone: (Optional) Defines the zone that a node lives in. Any host will escalate a cache lookup to nodes in the same zone first before looking at nodes in other zones.

The share identified by network path must exist on all nodes in the cluster, with the application pool user identity being granted read permission on the share (i.e. no remote write permission is required). The local on-disk cache path must have read/write/modify permission granted to the application pool user identity.

Testing the cache

The WAX configuration tool provides the ability to manage and test the cache settings, whatever cache mode you have selected. This feature can be accessed from the Options menu -> Cluster Manager.

WAX cache test UI

The More details link provides detailed information about the cause of any problems.

You should always run the Verify Cluster step whenever you add or remove a node from the cluster. Nodes that are taken out of load-balancing rotation for servicing or due to failure should be removed from the list prior to being made unavailable.

If performing a new install, it is possible to run this test with WAX switched Off – this allows you to verify that the configuration of each server is correct before switching WAX on and starting to accelerate requests.

Set LogInfoLevel to Error

To ensure that the minimum of noise from the Website Accelerator in the event log, LogInfoLevel should be set to Error when running in production. At this level, only initialization info events and errors are reported. Events that are reported as errors in the logs should be investigated, as they could be causing a disruption to service for some users.

Note: Error is the default value for logInfoLevel when in Production mode, so if the logInfoLevel attribute is not specified this will be assumed.

In addition to being logged to the internal Aptimize log files, errors are also written to the Windows Application event log. Any errors logged here will appear from the event source “WAX” – for production site monitoring, you can use this event source to forward these messages specifically to an operations team member who understands how to respond to the error.

An error may sometimes be reported while appearing to have no effect on the behavior of the system – if a false alarm like this occurs, you can silence the logs for this specific error code using the suppressedErrorCodes setting. In general, only repetition of errors are a cause of alarm – an isolated error is not likely to cause any impact to users. For example, if you see many WAXERR_2007 errors in the logs it is likely that the disk cache is invalid for some reason, or that one node in the cluster is malfunctioning.

Set CacheMaxMemory appropriately for the size of your site

It is recommended that you set cacheMaxMemory to approximately 10 times the size of the content that is cached to allow for different browser versions and compression schemes. An easy way to determine this is to clear the in memory and on disk caches (delete the files from disk and recycle the worker process) and then browse to a representative page of your site. Note the total size of all files in the disk cache, then multiply that number by the estimated number of page templates in your site and then by 10. It is not necessary to retain all resources in memory cache all the time, but frequently accessed resources should ideally not be expired due to memory constraints.

<wax:configuration cacheMaxMemory="200">
</wax:configuration>

Note: the cacheMaxMemory attribute is shown on it's own above - a real configuration file would have many other attributes already present, so you should add cacheMaxMemory in addition to these other existing attributes.

Move log files from default location

If your servers use a common location for logs that is on a separate hard disk or partition from the system files, then you can tell WAX where to store it’s log files:

<wax:configuration ... logFilePath="e:\logs\WAX\example.com" ...>

WAX automatically cleans up log files when they exceed the default maximum number of hours to be kept, but if your site is very busy then these log files may be many megabytes. Under normal conditions, as long as your system drive has plenty of space then the default location is fine to store these files – if you plan to run a global debug trace in production under load, then you probably want to move your logs first as this can produce large amounts of trace data.

Aptimize

Windows Version

Support