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
