I'm thinking about doing a second post with some actual code (some parts may be specific to Python, Django, and Celery) if anyone is interested.
Yes please, I love reading posts like this... it makes me motivated to learn more about these software!
Redis at Disqus
31–40 of 42 posts
Re: Redis at Disqus
#32Earlier quoted context omitted.
Not if you're trying to save RAM (and operations to fetch said data) by storing stats per day. You'd need all stats to be per-hour in order for it work for any timezone.
If you store by day UTC, you'd need two fetches to get a day in some other time zone. But if you store by hour, you need 24 fetches.
They can't in their (Disqus) case because they're aggregating all the stats per day into a single value. I guess they could do it 'per account TZ' since the account name is in the key, but that means TZ calc on each write (not that that will make a huge difference in perf).
For a generic solution with easy TZ calc, you need to aggregate your stats into hourly values instead (or half hourly if you care about those wacky non-aligned timezones). The increased fetches don't matter because you can just mget them.
Re: Redis at Disqus
#33I'm thinking about doing a second post with some actual code (some parts may be specific to Python, Django, and Celery) if anyone is interested.
What python client are you using? I have been mentioned few times about the performance.
If I remember, guys at bump did their own client in different language.
Re: Redis at Disqus
#34I started experimenting with Redis for the last couple of weeks and I'm really loving it's power. I most rely on posts like these to find new ways to use it.
And your way of sharding definitely gave me more insight into distributing Redis across many nodes
Re: Redis at Disqus
#35> While the VM backend helped, we found that it still wouldn't stay within the bounds we set, and would continually grow no matter what we set. We did report the issue but never came to a good solution in time. For example, we could give Redis an entire 12GB server and set the VM to 4GB, and given enough time (under high load, mind you) it would climb well above 12GB and start to swap, more or less killing our site.
We came across this same issue while implementing a Redis-based solution to improve the scalability of our own systems. Someone filed an issue reporting this: http://code.google.com/p/redis/issues/detail?id=248.
Basically, antirez confirms that Redis does a poor job estimating the amount of memory used, so you'll need to adjust your redis.conf VM settings to take this into account. For anybody relying on Redis's VM, I'd recommend writing a script to load your server with realistic data structures with sizes you expect in production. You can then profile Redis's configured memory usage vs. the actual memory usage point at which swapping starts occurring, and set your redis.conf according to the limitations of your box. For example, we run Redis 2.0.2, and using list structures with ~50 items of moderate size, we found configuring Redis to use 400MB actually resulted in it using up to 1.4GB before swapping. We configure our settings to take this into account. Mind you, this may all change with diskstore, and later versions of Redis which are supposed to be more memory efficient.
For those curious, our Redis-based solution is helping us scale some write-heavy activities quite nicely, and has been running stably.
Re: Redis at Disqus
#36I'm thinking about doing a second post with some actual code (some parts may be specific to Python, Django, and Celery) if anyone is interested.
Definitely interested in both code and your Redis config files.
Re: Redis at Disqus
#37Earlier quoted context omitted.
I'm definitely interested. Also, out of curiosity, what do you use to render the actual charts? I'm working on an analytics package and can't decide on a charting engine that is clientside and reasonably performant.
We went through several different iterations of the line charts. Initially, I tried using SVG via Raphael, but it turned out to be too slow. Because it's possible to have a significant number of data points, manipulating and changing the SVG markup was causing too much of a it. Eventually we settled on using Flot, which is a canvas-based charting solution. We made some changes to the core Flot code with some plugins…
Thanks for the info!
flot is what I settled on, too, but performance with a lot of datapoints was not so great. Maybe it was just too much data. Also, the timeline view was really annoying, but JS' Date function are to blame for that. But with Flash out of the question and Raphael even slower, I suppose it's the best option for now.
Re: Redis at Disqus
#38Earlier quoted context omitted.
We went through several different iterations of the line charts. Initially, I tried using SVG via Raphael, but it turned out to be too slow. Because it's possible to have a significant number of data points, manipulating and changing the SVG markup was causing too much of a it. Eventually we settled on using Flot, which is a canvas-based charting solution. We made some changes to the core Flot code with some plugins…
Thanks for the info! flot is what I settled on, too, but performance with a lot of datapoints was not so great. Maybe it was just too much data. Also, the timeline view was really annoying, but JS' Date function are to blame for that. But with Flash out of the question and Raphael even slower, I suppose it's the best option for now.
How many datapoints are you using? One things that I've done (though in the end, we didn't need it realistically) was use a resolution function to tune the datapoints to fit the canvas width.
If your canvas is only, say, 400 pixels wide, then any time series datapoints more then 400 will get lost -- there's simply not enough pixels to display them accurately. As such, you can use a resolution function to reduce that down to 400.
Re: Redis at Disqus
#39dfgdfg
Re: Redis at Disqus
#40Earlier quoted context omitted.
Thanks for the info! flot is what I settled on, too, but performance with a lot of datapoints was not so great. Maybe it was just too much data. Also, the timeline view was really annoying, but JS' Date function are to blame for that. But with Flash out of the question and Raphael even slower, I suppose it's the best option for now.
How many datapoints are you using? One things that I've done (though in the end, we didn't need it realistically) was use a resolution function to tune the datapoints to fit the canvas width. If your canvas is only, say, 400 pixels wide, then any time series datapoints more then 400 will get lost -- there's simply not enough pixels to display them accurately. As such, you can use a resolution function to reduce that…
I have way more; I downsample to temporary mongodb collections and display the closest resolution for the available width.
I also found it hard to decide on a resolution function for analytics. Do we show the maximum of a time range? The average? Median? Min and max?