Get Your Free Carrier Cache Here!

Download

Carrier Cache Trial for Linux

Carrier Cache Trial for Linux with Spectre Variants 1 and 2 Mitigation

Carrier Cache Trial for macOS

Decompress

Extract your Carrier Cache Trial download (example: linux):

tar xfvp carrier-cache-9.4-linux-trial.tar.gz

Your Carrier Cache download includes multiple micro-architecture optimized binaries, but you don't need to worry about figuring out which one to use. Carrier Cache ships with a server launcher (one of carrier-cache or carrier-cache-trial or carrier-cache-trial-spectrev12) to auto-detect your CPU type and picks the most optimized binary automatically.

Run

Now launch Carrier Cache Trial by running the carrier-cache executable (example: linux).

cd carrier-cache-9.4-linux-trial
./carrier-cache-trial

You're now running Carrier Cache! Carrier Cache launches with a quick summary of your configuration including, but not limited to:

Demo: Get Server Statistics

Carrier Cache supports the entire memcached command set, but unlike memcached, Carrier Cache stats are JSON compliant.

Global Stats

You can quickly get the server stats JSON output with the standard memcached stats command:

printf "stats\r\n" |nc localhost PORT

Global Stats Formatted

By default all JSON is returned flattened. You can also request properly indented JSON with stats visual:

printf "stats visual\r\n" |nc localhost PORT

Pipe Stats to `jq`

The memcached protocol requires output of unknown length have END\r\n as the final line, but for piping through command utilities over one short lived connection, that's just noise.
Carrier Cache has an option to remove the END\r\n marker with stats noend:

printf "stats noend\r\n" |nc localhost PORT |jq

Pick Stats by Section

By default, stats returns all statistics. You can also request individual sections after any formatting options:

printf "stats visual noend cpu memory\r\n" |nc localhost PORT |jq

Connection Stats

Server stats are great and all, but what about client stats? You can view the stats of your current connection with self stats. Connection stats shows request counts, transfered byte counts, and if your are on a TLS connection you will see negotiated encryption details and encryption overhead stats collected over your entire connection.

printf "self stats noend\r\n" |nc localhost PORT |jq

Note: for single command stats testing, the key self.transfer.total.write will always be 0 bytes because server sent accounting is calculatedafter data is written to your client, but in this case your client just disconnects.

Commands Supported

Carrier Cache supports the full memcached data command set: SET, ADD, REPLACE, CAS, APPEND, PREPEND, GET, GETS, DELETE, INCR, DECR, TOUCH in addition to admin commands: FLUSH_ALL, STATS plus some custom Carrier Cache commands: ADMIN LOGLEVEL SET, SELF STATS.

Any Client

You can use any existing memcached client for Carrier Cache too. Since memcached has never supported encryption, you may need to add TLS connection support to some clients. Typically converting to a TLS connection API from a regular TCP connection API will require just copying the existing client connection method then using TLS APIs instead of TCP APIs.

All Options

Carrier Cache features:

noreply on relevant commands
DELETE can accept multiple keys at once
Commands and options are case insensitive in Carrier Cache
If you are on a client network with admin permission, you can FLUSH_ALL [delay] as well as change the log level at runtime with ADMIN LOGLEVEL SET [EMERGENCY|ALERT|CRITICAL|ERROR|WARNING|NOTICE|INFO|DEBUG]

Optimize Your Config

Carrier Cache is best used with a config file specified as:

./carrier-cache --config myconfig.conf

You many want to tune some parameters to be more or less aggressive than Carrier Cache's default heuristics.

Here's a quick introduction to common settings. Full settings documentation is at our Carrier Cache Tech Specs page.

Thread Counts

Carrier Cache has three thread pools for highly scalable request processing:

inbound protocol parser thread pool
data worker thread pool
outbound reply generation thread pool

Set thread counts for each pool with configuration options:

runtime {
    protocolParserInstances 5
    dataWorkerInstances 80
    networkReplierInstances 20
}

LRU

Carrier Cache has three LRU modes each with different space/time efficiency for highest flexibility:

random eviction
- fastest and smallest. zero additional memory usage
random eviction with memory
- fixed amount of extra memory usage where eviction tries to pick least accessed keys
segmented LRU
- a full in-order LRU with user-defined boosting segments. A segment count of N=1 means no boosting (traditional LRU). Higher segment counts boost accessed keys one level at a time up to the highest level allowed. N=4 provides S4LRU.

Why does Carrier Cache use multiple thread pools? Because encryption processing overhead is expensive. When you create TLS-enabled networks, Carrier Cache can decrypt incoming connections, process the data of existing requests, and encrypt outgoing connections all concurrently up to the scale of your entire server. Also, client replies are generally larger than requests, so you can assign more CPU resources to encrypting replies than you need to assign for the smaller inbound requests.

Set LRU mechanism and define memory limit to trigger LRU:

lru {
    enable yes
    mode random
#   mode random-memory
#   mode snlru
#   snlruLevels 4
}

memory {
  softStayUnder 50 GB
}

Your Carrier Cache memory limit is defined by config key memory.softStayUnder. The limit is 'soft' because Carrier Cache will only trigger LRU removal when memory usage grows above the limit. If you define a memory limitwithout enabling an LRU policy, writes will be rejected until you manually delete data to reduce memory usage under your configured limit.

Networking

Carrier Cache allows you to define an unlimited number of named networks with a simple config syntax each with their own security settings and access controls.

Each named network also collects its own independent usage statistics for global stats reporting.

Each network may define any or all of:

host - any hostname or IPv4 or IPv6 address to bind for listening (default: localhost)
port - port number clients connect to (default: random)
ipv6only - bool, only bind to the IPv6 interface of a given hostname (default: no)
certchain - full path to signed TLS certificate
privatekey - full path to private key for certificate
enabletls - bool, whether to enable TLS for network (default: no)
access - string, configures access permission for network (default: no access). Must specify a string with any of access "admin stats read write". If an option is absent, it is disabled.
maxsessions - integer, maximum concurrent clients on this network before connections get rejected (default: unlimited)
securityOverrideAllowPublicIP - bool, for positive security acknowledgment you must explicitly enable this override if you bind to a public IP address (default: no)
securityOverrideListenOnAllInterfaces - bool, for positive security acknowledgment you must explicitly enable this override if you bind to a wildcard interface (default: no)

Network config examples:

network mySuperAwesomeSecureNetwork {
    host localhost
    port PORTNUMBER
    certchain /path/to/signed-cert.pem
    privatekey /path/to/private-key.pem
    enabletls yes
    access "admin stats read write"
}  

network myUnawesomeInsecureNetwork {
    host 4.4.4.4
    port PORTNUMBER
    access "read"
    securityOverrideAllowPublicIP yes
}

Optimize Operations

Improve the performance of Carrier Cache with these tips for efficient encryption settings and tuning runtime parameters for time vs. space tradeoffs.

Generate Efficient TLS Key and Cert

Generate your private key and certificate using efficient parameters:

openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private-key.pem
openssl req -x509 -newkey rsa:2048 -keyout private-key.pem -out cert.pem -days 8192 -nodes

The above private key uses a secp521r1 curve, but you can use any curve listed by:

openssl ecparam -list_curves

The private key curve you pick must also be supported by the library your clients use for TLS.

Carrier Cache supports listing multiple TLS certificates and keys per virtual server block, so you can provide clients RSA and ECDSA keys on-demand as required.

Concurrent Thread Queue Sizes

Carrier Cache uses multiple concurrent thread pools to enable efficient parallelism on servers from just a single core up to thousands of cores, but we must have a way to pass data between all our live threads. For best performance, you may need to tune Carrier Cache's internal communication queues.

Carrier Cache uses lock-free multi-threaded queues allocated on startup to communicate between worker pools. You can scale Carrier Cache up (using large queue sizes) or down (using smaller queue sizes) to balance performance requirements.

By default, each thread queue holds up to 4096 messages. If a queue is full but has incoming messages, Carrier Cache will pause the writer until a slot opens up.

If you expect your server to have more than 4096 requests in flight at once, you'll want to increase the queue sizes using the runtime.msgQMultiplier config parameter.

Here's an example of increasing message queue size 3 times larger than default to a maximum of 32,768 concurrent processing slots in flight (increases are in powers of 2; default is 4096 = 2^12, and we add 3 more powers of 2, so now we have 2^(12 + 3) = 2^15 = 32,768 slots per thread queue):

runtime {
    msgQMultiplier 3
}

Deploy to Production

Final steps to deploy the most scalable and memory-efficient cache to production:

pick up some production licenses
configure daemon and logging settings
deploy, deploy, deploy

Production Config Options

process {
    background yes;
    pidfile "/tmp/carrierCache.pid";
}

log {
    level INFO
    file "carrierLog.txt"
    stdout no
    syslog yes
}