HN Explorer

Ask YC: Concurrent vs. Registered User Ratio?

11 points by bsaunder ↗ HN
Does anyone have any numbers they could share on the number of registered users (or active ones), vs the number concurrently using the system at peak times. I'm trying to estimate the size of the production systems I will need.

7 comments

[ 3.3 ms ] story [ 30.3 ms ] thread
izaidi
My site's still pretty small but I've got 1800 registered users, an upper limit of around 300 active ones, and 10 to 15 using the site at peak times.
t-dub
I think that this is somewhat dependent on the sort of site you're looking at. Total user engagement and usage patterns are going to be different on a news site is going to be different than on a social networking site.

In any case, on a fledgling social media (i.e. focus on sharing/remixing audio/video/images) that I built for a client, the current user registration is just shy of 2,000. The number of users who have posted anything is ~700. The number of users who have posted in the last 30 days is ~350. The number of users who have posted 3 or more items in the last 30 days is ~100. The number of users who have commented on a post in the last 30 days is ~150.

t-dub
Heh, I just realized I never answered the concurrency issue. The all-time peak for concurrent users was about 45. More typical is 15. However, there is a live audio stream associated with the site which probably tends to encourage more concurrency.
xirium
> usage patterns

Session duration will greatly influence concurrent usage. If people use your service for less than five minutes per day then 100 daily users would mostly have the system to themselves. This means that you could have thousands of registered users and grossly inefficient code without load issues.

Stop fretting about your hardware and get thousands of registered users.

bsaunder
Thanks. I expect my sessions to be longer (30 minutes?). And if I were only expecting hundreds of users, I wouldn't waste my time. I'm hoping to hit at least tens of thousands of registered paying users. I do expect to have portions of "grossly inefficient code" (much faster to implement in some cases) initially that I plan on solving (when they become the problem to solve). My product/site will be highly collaborative (I know, everyone thinks this, but, I think my idea is different (I know, everyone thinks... ())) and with a larger than normal communication component.
bsaunder
Thanks, I suspect that my site will have rather long sessions (30 minutes?). I plan on supporting anonymous, free, and paid users. I suspect that most of the users will be anonymous and/or free (I'm considering advertising for some of these. My system will also have a higher than normal communication component (a key factor in my concern on sizing).

My guess is that I should plan for a concurrent user load of about 5%-10% of the registered users (both free and paid). Included in that range would be the unregistered anonymous users. I expect at the end of the day the actual concurrent usage will be much lower. Probably less than 1%. But I don't think the hardware costs to support 5-10 are five to ten times the cost of supporting 1% (probably a factor of 2 or 3).

sanswork
Most of the sites I've worked on top out at 1% of registered users online at any given time.