Memory Settings and Server Speed - A Non-Programmer's Guide to Web Crossing

Web Crossing is a professional, industrial strength online community system and provides an incredible number of features, full customizability and linear scaling to the point that any sized community can be supported. To achieve maximum performance, Web Crossing uses quite a lot of random access memory - RAM. To state it most simply, the more RAM allocated to your Web Crossing server, the faster it will run.

In fact the difference between allocating sufficient memory and allocating insufficient memory can be dramatic. If you are running without enough memory, you might feel your Web Crossing server is sluggish and unresponsive. Tweaking up your memory allocation to provide enough memory to Web Crossing can result in an instant, overwhelming improvement in performance.

How much memory is enough? How can we tell if we are running with insufficient memory? How do we change the memory allocation?

Fortunately, Web Crossing memory settings are conveniently divided into three numbers - the small object heap, the disk cache, and the attachment cache - and all are easily set in the Control Panel. Go to Control Panel > Memory Usage and you will see the following settings:

The values entered are in Kilobytes. That is, 1024 Kilobytes equals one Megabyte. The settings shown in figure 1 might be different from those in your control panel.

Note: Resetting the memory usage values forces the small-object heap to be reset, resulting in a sysop logout. You will need to login again as sysop in order to access the Control Panel again.

Note for Mac Servers: You must insure that the application has sufficient memory allocated to the Web Crossing server application in order to increase the values in the memory usage control panel. This must be done while the Web Crossing server application is not running. Select the Web Crossing server application icon and choose "Show Info" from the File Menu. Choose "Memory" settings and adjust the application memory to allow for any increases you set in the memory usage control panel. If your requested cache sizes doesn't match the actual sizes shown, this is the problem. (Application memory is set automatically in Unix and Windows, including Mac OS X Server. This just needs to be done if you are running your server on Mac OS PPC.)

Small-object heap

Note that the message below the Small-object heap settings in figure 1 reports that since the last server reset there have been 0 memory reclaims. If you can adjust your Small-object heap so that you achieve zero reclaims, or close to zero reclaims, over a long period of time then your Web Crossing server will be running at optimal speed.

The trick is to add more and more memory (if you have the RAM on your server machine!) until you stop getting reclaims. Since reclaims occur over time, while Web Crossing is actually serving, you should wait a while, perhaps a day, and come back and check your settings to see what the current memory usage report tells you about the amount of memory reclaims going on.

Generally, the more memory you are able to give to the small-object heap the faster your server will run. Of course, you cannot give more memory than the physical RAM available to Web Crossing. Attempting to give more memory than your machine can provide can result in an actual reduction in performance. So you should be aware of the total memory resources available in your server machine.

Disk cache

The disk cache figure is generally never zero. It is perfectly normal for this figure to gradually increase over time. It is suggested that the optimal disk cache size is about one-third the size of your webx.db database file. Often you can get by with one-sixth the size of your database without noticing any real reduction in performance.

Note: There are limits to the values you can enter in the disk cache and small object heap areas:

	Minimum	Maximum
Disk Cache	600 KB	2 GB
Small Object Heap	600 KB	1.5 GB

Attachment cache

The attachment cache reflects the maximum memory space that will be used to cache attachments, so you save cache space for other more important operations. If you have attachments turned off on your site, you can safely set this to 0. Increasing this number means that attachments will be served more quickly, with fewer reclaims, but also means that memory is taken away from the disk cache and small-object heap. There is no maximum or minumum attachment cache size.

Improving performance

The bottom line is this - memory is very inexpensive these days and you should generally add all you can afford to your critical server machines, including those running Web Crossing. A small investment in memory will provide you with a satisfyingly speedy serving environment.

If you just cannot add more memory, then your best option is reducing the size of your discussion database by deleting discussions (either manually or by making use of the automatic archiving features in Web Crossing) and repacking your database to attempt reducing the database size by removing old, deleted references. You can do this by:

Deleting unnecessary discussions and folders.
Backing up your server with the Repack option selected. (See Control Panel > Backup.)

This will reduce the overall size of your webx.db database file, resulting in lower memory requirements.

Using Command Code 199

Many of these same settings are reported on the "command code 199" page, although you can't change them there. The advantage of viewing these settings via this page is that it doesn't count as a page view for licensing purposes.

To see the command code 199 page, use this formula:

http://www.yoursite.com/webx?199@@

Resources

Sysopdocs