AuthenticationTokenCachingPolicy

The AuthenticationTokenCachingPolicy configuration setting in xWeb determines if Authentication tokens are managed in a database table or in server memory cache.

NoCaching manages tokens in the database and is the default. WebServerCache manages the tokens in server memory.

Abila added the token caching feature in an attempt to minimize performance degradation under very high loads. In an xWeb site with a relatively modest load (under 500-1000 xWeb calls per minute), either option performs relatively the same.

But under a higher load, over a more sustained period of time, we have found that the token caching setting outperforms the no-caching policy.

Load testing has shown that the token caching speeds the Authentication method the most, as this saves us one insert command (to insert a token) and one select command (to check for faults and failures). Subsequent web methods, however, see less of an improvement, as they are spared only one update command.

In general, there is no right or wrong way to configure this option. We recommend you try both options, measure the results, and choose which one offers the best performance for your unique scenario.

Options

NoCaching

With this option tokens are managed within a netFORUM database table called ws_security. This setting is the default.

WebServerCache

The WebServerCache option manages tokens in server memory using .NET's System.Web.Caching feature. This option bypasses the token security table altogether. With this option, xWeb has less traffic to and from the database server but uses more memory to maintain tokens in cached server memory.

One issue with caching tokens is that if an xWeb User gets locked out, and you want to unlock them, the only way to unlock them is to restart the xWeb application. With the NoCaching option, you can delete the Fail/Fault tokens from the database and from the User page.

Caching Best Practices

If you choose the Caching option, you gain by having fewer database calls, but you lose by requiring the xWeb web server to spend more memory on managing the cache. Therefore, if you go with caching, then you want to keep the memory usage light and make the most of this setting by doing the following:

• Choose the Absolute Expiration policy and ask your integrators to design their applications to call the Authenticate web method sparingly. See Authenticate case study for a way to call this web method only when needed.
• Keep the Timeout setting low if you are not keeping Authenticate down to a minimum. When a token is generated, it stays in cache as long as the Timeout. Therefore, if you generate lots of tokens, and you have a long timeout, then your xWeb server will need to maintain a large cache.