How is Sixpack handling Redis Storage?

[nickveenhof]

Is it ever invalidating data or does it expect Redis is an ever-growing storage? Could the maintainers shed some light on this please? Useful to know when Sixpack would be running for months to come. Thanks

[josegonzalez]

It's up to you to maintain, archive, and delete redis data. Sixpack doesn't do anything special in this regard, it simply uses redis for data storage.

[zackkitzmiller]

@nickveenhof Sixpack mostly uses the bitwise redis operations to keep memory usage as low as possible. At SeatGeek we have never ran into any memory-related with Sixpack using Redis as a datastore.

[nickveenhof]

https://www.evernote.com/l/ACxwKD9nD7VM3amtW6tmrM3YyYZEmb28sNoB/image.png

Here's a graph of the memory usage of Redis while SixPack was used. Another application is also using the cache but, as you can see from the graph, those are removed from memory after a while. When running high volumes of traffic, I see this might become an issue in the long run. Is all the data necessary in redis or can we give sixpack an option so that it adds TTL values to the decisions that were made for example? Or is it possible to implement an API call in Sixpack to purge the data of a certain experiment for example?

[nickveenhof]

This issue was also closed way too early and too quickly. Please give me some time to respond.

[josegonzalez]

A few things:

• Adding an automatic TTL to data seems like a bad idea. It's not intuitive that Sixpack would be deleting data, and users may want to have different archival methods (we currently pull closed experiment data into redshift).
• It's possible to use Sixpack as a way to implement feature flags, and we do so at work. We do like keeping the data about how the usage impacted conversions around, even when a feature is "disabled", so having the data disappear sounds like a bad idea.
• You can use the web ui to delete experiments. The endpoint is here. It's not exposed in the server interface as you might have external users maliciously deleting your data.

[nickveenhof]

I agree with your points of retaining the data, our use case logs all information but processes it continuously. Since we store our data in a more persistent way (non-redis) we no longer need that data when an experiment hasn't been active for, say, 30 days. Would sixpack be open to such a feature "remove inactive campaigns after 30 days when option was set" so that sixpack server could be started with this option. It could have a cron job and find out all campaigns and figure out when its latest activity was and clean it up.

To your point of removing a campaign in the web-ui, why would it even be in the web-ui as an endpoint? For example, we are not using the web-ui since we do not need it for our analysis. Those two should be fully independent. The web-ui should never be the canonical source for deletion of your data imho, the server should be.

Thoughts?

[josegonzalez]

The server is exposed to the outside world - in the case that you are converting via JS requests - and thus we opted not to implement a delete endpoint there.

We implemented it in the web-ui as the web-ui is used for management - that is to say, we can and do use it to pause/resume/restart tests, just as you would with the old GWO.

If you want to add an endpoint to expose metadata about a test, I wouldn't be opposed to it. You could then implement your own cron task based on this.