Nick, Have you looked into memcached [1]? Attribute-value pair caching is what it was designed to do. Perfect for the write-through cache that is needed here. It will also handle the pesky details like resolution expiry for you, too. If you would like help, ping me offline, I can get you started.
[1] - http://www.danga.com/memcached/ Doug Williams @dougw On Fri, Mar 6, 2009 at 2:49 PM, Nick Arnett <nick.arn...@gmail.com> wrote: > > > On Fri, Mar 6, 2009 at 11:15 AM, Doug Williams <do...@igudo.com> wrote: >> >> Nick, >> Are you using a caching layer? Initialization of the cache will of >> course be slow since every user will need to be looked up with a >> users/show call, but the cache should eventually pay off after the >> most active users have been entered. > > Yes, I'm putting them into a database... it is especially slow because I > decided to capture the status data in addition to the user name, so there's > a fair bit of overhead. I'm going to code up a light version that just > grabs names and see how much faster it is. I'm fairly sure it's nothing > people would want to wait for in real time... so as you say, building up the > cache is the key. > The speed of my current code is also limited by the database, which is > CPU-bound. I'm using an old server that will benefit from a lot more > memory, which I'm going to go and purchase this afternoon! I haven't > offered any hard numbers because of these constraints... and I may be > bandwidth-limited some of the time. > I'll post some numbers at some point. I'm wondering how many unique screen > names I'm getting, on average, per API call (it's less than 100 because > there will be multiple statuses for some people) and what the average > latency is. Those are things I can't control, so they ultimately will > create the upper boundary. > By the way, I'm not just looking at this as a problem. It's also an > opportunity and I may have a source for the resources to address it. > Nick -- Doug Williams do...@igudo.com http://www.igudo.com
