SysLog is a method for logging errors or other information to a system logger. This section of settings allows the system administrator to configure RumorMill to log data to the SysLog server.
In general this should be left blank to allow RumorMill to use a default value. However, if necessary this value can be configured to any string value. A short string is preferable since this text will become part of any article posted to your copy of RumorMill.
The system administrator may change the name of the log file to any name.
RumorMill has an optimization that will immediately forward small articles to the remote server when streaming is enabled. This optimization is appropriate when articles are small rather than incurring the overhead of first asking if the remote server wants this small article and then sending when told yes. It is inappropriate to make this setting large as you may be putting an unwanted load on your downstream news peer.
When pulling articles from a remote newsfeed, RumorMill uses the "NEXT" command to get discover the next article to retrieve. However, this causes and extra round trip between the remote news server and RumorMill. Faster pulling can be achieved by disabling the use of NEXT. However, if the group of articles RumorMill is pulling is sparse, RumorMill will potentially send many bogus requests for the next article in the group. This may be frowned upon by the SysAdmin of the remote newserver.
Enabling this radically improves the performance of RumorMill. The performance improvement comes at the expense of some additional memory usage. This option is strongly recommended.
Some news reader clients are capable of using the XPAT command. Use of this command can improve performance (response) for the client. Depending upon the client implementation, using XPAT may also reduce load on the server. However, it is more likely that the use of XPAT will put more demands on your server (more CPU requirements).
This section allows the SysAdmin to determine how often various databases are compressed to save space on the disk. In general, active databases like the "Message IDs" and "By Group Index" should be compacted more often than less frequently changing databases like "Users." In addition, the periods should be choose so that not all databases are compacted on the same day.