I'm curious about what you mean by 'most amount of people you have had on your site at one time'. This can mean a few different things...
1) For monitoring applications like Chartbeat, IIRC they count a user as concurrent if they are on the site anytime within the past 30 seconds.
2) I've seen real-time monitoring systems count a concurrent user as any visitor in the last 5 seconds.
3) Lastly, the only real raw numbers that I've seen are the traffic hits through an F5 load balancer to a set of backend servers, and that is the only number that will give you an unbiased # hits per second in real-time. Unfortunately, this amounts to requests (HTML) to the server and may not be a 1:1 ratio with users.
So in terms of what I've seen, it depends on the type of calls and the application. For the EA forums (forums.ea.com) which I was in charge of up until March 2013...
For #1, forums would regularly reach 15,000 on the launch of a new game. We would sustain that for ~12 hours [1]. On just an average normal non-event day, it pushes 3000 concurrents.
For #2, I've seen something north of 3000 for EA forums.
For #3, the F5 would report peaks of 200 requests per second.
When I built the Campus Wide Login (http://www.cwl.ubc.ca) SSO auth system for UBC about 11 years ago (still in use today) we would have almost 50-75% of the full campus using it at once, which is about 30k concurrents (unfortunately I didn't have access to the numbers over the F5 LB). However, most of these calls were for the HTML which then went through an SOA (XML-RPC, ugh) architecture, so I'm sure the req/s was much higher on the XML-RPC backend.
[1] this is a feat in itself because most of the forum data is not cached because the business wanted the data in real-time, so the read databases would receive a lot of traffic when the web servers spiked.
Comments
I'm curious about what you mean by 'most amount of people you have had on your site at one time'. This can mean a few different things...
1) For monitoring applications like Chartbeat, IIRC they count a user as concurrent if they are on the site anytime within the past 30 seconds. 2) I've seen real-time monitoring systems count a concurrent user as any visitor in the last 5 seconds. 3) Lastly, the only real raw numbers that I've seen are the traffic hits through an F5 load balancer to a set of backend servers, and that is the only number that will give you an unbiased # hits per second in real-time. Unfortunately, this amounts to requests (HTML) to the server and may not be a 1:1 ratio with users.
So in terms of what I've seen, it depends on the type of calls and the application. For the EA forums (forums.ea.com) which I was in charge of up until March 2013...
For #1, forums would regularly reach 15,000 on the launch of a new game. We would sustain that for ~12 hours [1]. On just an average normal non-event day, it pushes 3000 concurrents. For #2, I've seen something north of 3000 for EA forums. For #3, the F5 would report peaks of 200 requests per second.
When I built the Campus Wide Login (http://www.cwl.ubc.ca) SSO auth system for UBC about 11 years ago (still in use today) we would have almost 50-75% of the full campus using it at once, which is about 30k concurrents (unfortunately I didn't have access to the numbers over the F5 LB). However, most of these calls were for the HTML which then went through an SOA (XML-RPC, ugh) architecture, so I'm sure the req/s was much higher on the XML-RPC backend.
[1] this is a feat in itself because most of the forum data is not cached because the business wanted the data in real-time, so the read databases would receive a lot of traffic when the web servers spiked.
Edit: formatting