NxFilter Tutorial
Tutorial Index

Performance tuning
Although NxFilter is designed to handle several thousand users easily there are several parameters you can adjust to get the best performance.


Memory size
At default, NxFilter uses up to 768 MB RAM. This is enough for most users. But if you allocate a bigger memory to NxFilter you can expect a better performance. In NxFilter startup scripts, '/nxfilter/bin/startup.sh' you have a start option like below,


	java -Djava.net.preferIPv4Stack=true -Xmx768m

If you want to increase it to 2 GB then change '-Xmx768m' to '-Xmx2048m'.

If you have enough memory for NxFilter, you might want to use '-server' option for starting Java. It requires more memory but you will get a better performance.


Reducing the amount of log data
NxFilter has various logging/reporting  features. These kinds of features require a lot of disk space. When you have a huge size of reporting data your system may experience a performance degrading.

If you have more than several hundred users, it might be better to have at least 10 GB of disk space for the traffic DB. Or to save the disk space, you can reduce the size of traffic DB. To reduce the size of the traffic DB, you can adjust the value for 'Log Retention Days'  on 'Config > Setup'.

The other way of reducing the amount of traffic data is to make a whitelist with 'Bypass Logging'  option for the domains you are not interested in.


Increase the number of request handlers
NxFilter is a multi-threaded program. It has multiple worker threads processing client DNS requests. The default number of request handler is 8 and it is enough for most cases. But if you think your NxFilter responding slowly, you can try to increase it. To increase it to 16, add the following line into '/nxfilter/conf/cfg.properties' and restart NxFilter.

    rh_num = 16


Client cache TTL
NxFilter can manipulate client cache TTL. On 'DNS > DNS Setup', there are 'Minimum Cache TTL'  and 'Block Cache TTL'. You can increase these values to reduce the amount of DNS queries from your client systems.


Avoiding 'Database Connection Bottleneck'
As of v4.3.4.4, NxFilter slave node uses its own local Jahaslist DB at defalut. This is for older versions.

In NxFilter clustering, a slave node is supposed to use or share the database of its master node for not having any inconsistency between the nodes. However, when you have busy servers, you can have too many database connections from your slave nodes to your master node and that may degrade the performance.

For main configuration database, we don't have this kind of problem since we load the database into the memory space of each node. But for a domain categorization database, you still can have 'Database Connection Bottleneck' problem as we can't keep it in memory space for its huge size. We can tell that this may happen when you have more than 3,000 users.

One solution is to use a cloud based domain categorization service as each NxFilter node has its own connection to these cloud based servers. Another solution is to separate database connection to each node. For Jahaslist, we support 'use_local_jahaslist' option on its config file. To enable the option, add the line below into '/nxfilter/conf/cfg.properties' of a slave node and restart it.

    use_local_jahaslist = 1

Now your slave node will use its own local Jahaslist database. There's a slight possibility of having inconsistency between your cluster nodes but it will be minimal as NxClassifier works with the same ruleset from its master node and it will try to copy the same classification from its master node when it finds an unclassified domain.

Before you enable 'use_local_jahaslist' option on a slave node, it's better to copy your Jahaslist database from your master node. You can use 'EXPORT' and 'IMPORT' buttons on 'Classifier > Jahaslist'  on GUI. Or you can directly copy '/nxfilter/db/jahaslist.h2.db' from your master node. When you copy it directly, you need to stop NxFilter first.