Storage

Faktory uses Redis for its persistent storage.

OSS

By default, Faktory will start and manage Redis as a child process. When you stop Faktory, it will stop Redis for you. Making a regular backup of your queue data is as simple as cp /var/lib/faktory/db/redis.rdb backup.rdb.

Faktory Pro

Faktory Pro adds the Redis Gateway feature which allows you to expose Faktory's Redis instance to the network so you can enable real-time replication.

Faktory Enterprise

Faktory Enterprise adds the ability to use a remote Redis for storage, so you can use a Redis SaaS which provides replication and high-availability. The performance of a remote Redis can greatly affect your Faktory experience, read on...

RTT

With remote storage, network latency and RTT (round trip time) become critical to the performance of Faktory. When running Redis locally, Faktory can guarantee a 100-200µs latency. However with a cheap or misconfigured SaaS instance, you might see RTTs greater than 50ms, which will make Faktory look and perform terribly. The /debug page shows the RTT when gathering the Redis info for the page and will color the entry red, yellow or green depending on the current value.

If your RTT is red, you should investigate why it is performing so poorly. The most important aspect is to ensure your Redis instance is running in the same Availability Zone as your Faktory instance. I've seen big AWS Elasticache instances showing RTTs as low as 150-200µs and cheap "Brand X" Redis SaaS instances which show consistent 10-20ms RTT. You get what you pay for (and configure correctly).