There are several options that can make your notary run even better.


1. Set up caching!

Data caching will significantly increase your notary's performance.

For best performance you may want to use a dedicated caching server such as memcached, memcachier, or redis. If you do not have access to or don't want to set up a dedicated caching server, use the built-in python caching with '--pycache'. It works automatically and is as easy as adding the switch!

1a. Cache duration

Longer cache durations mean less frequent fetching from the database, which improves performance. However, cache entries should be refreshed often enough that clients can see reasonably recent data (e.g. perhaps after every scan or every second scan).

The default Perspectives client settings ignore notary results that have not been updated in the past 48 hours. Because of this, you may want to set your cache duration so that the (scan frequency + scan duration + cache expiry) is <= 48 hours.

For example, if you run scans every 24 hours and scans take 10 hours to run, set your cache duration to (48 - 24 - 10) = 14 hours. If you run scans every 12 hours and they take 1 hour to run, you can get away with a cache duration of (48 - 12 - 1) = 35 hours. This will ensure that your cached data is always up to date and that clients are always getting current results.


2. Enable SNI scanning

Using 'Server Name Indication' causes notaries to provide extra information when scanning sites - some sites require this to retrieve the correct SSL certificate.

Add the '--sni' argument to both your main notary server (notary_http.py) and your routine scanning job (e.g. scans done with notary_util/threaded_scanner.py). This will ensure the notary has the correct certificate for all sites.


3. Database tuning

The observations table has many updates during normal behaviour as the end times for certificates are observed and extended. If you're using a database with configurable maintenance (e.g. vacuuming) it can be a good idea to increase the cleaning threshold for this table.

For Postgres:
	ALTER TABLE t_observations SET (autovacuum_vacuum_scale_factor = 0.1);


4. Socket Queue Size and Thread Pool Size

As explained by '--help', the socket queue size is the maximum number of queued network connections allowed by CherryPy, the web server used by this notary software. The thread pool size controlls the number of CherrPy worker threads that handle incoming requests.

If your notary runs in an environment with a fast network connection, fast routing, and adequate bandwidth you shouldn't need to adjust the defaults. However, if you are on a slower connection, increasing these values may help your server handle requests more quickly, up to a limit.

The Winsock Programmer's FAQ suggests a socket queue size of at most 200 [1], and notes that your program should be able to quickly deal with queued sockets so they don't sit for too long. Values below 50 should be adequate in most situations.

Increasing the Thread Pool Size will use more memory. In addition, due to the python Global Interpreter Lock, only one thread from a process can perform certain operations at a time. This means that a large thread pool won't necessarily increase notary responsiveness. If you need a large number of threads you may achieve better performance by running multiple notary servers behind a load-balancer (also known as a "reverse proxy") and having them use a shared cache and database.

When adjusting these settings you should test notary behaviour in your environment.

[1] http://tangentsoft.net/wskfaq/advanced.html#backlog
