Caching

If you are using split on a high traffic website you'll likely be using some variety of caching in your application.

This can interfere with running A/B tests as you may cache the template of an alternative and end up serving that to all users, invalidating your test.

Below are a number of different caching techniques used in Rails (and sinatra) and how best to use Split with them.

Page Caching

Page caching usually stores the full html contents of the page on disk, often with apache/nginx serving up the html directly, never hitting your application logic.

different urls or javascript

Fragment Caching

Fragment caching stores a segment of a page in cache referenced by a key which is then rendered or created by your application as the template is rendered.

This is the easiest form of caching to integrate with split as you can add your alternative name to the fragment's cache key, rendering the correct fragment for the alternative that the current user should be seeing

code example here

Action Caching

Action caching is where you store the result of the controller action of a page but allows before filters such as authentication.

some kind of logic in a before filter to render or direct to a different controller action or javascript

Proxy caching

Proxy caching is where you place software such as Varnish between your web server and your users, it then uses the standard http expires and cache control headers to determine if the page should be cached or reloaded from the rails app.

Often this will mean that a user never interacts with the routing or controller logic of your application.

different urls or javascript