3 ms·

Tumblr is an extremely pageview heavy design, but the industry has moved away from PV as an important metric for a few years now. Fortunately they're nice enou

by cagenut 15y ago

Tumblr is an extremely pageview heavy design, but the industry has moved away from PV as an important metric for a few years now. Fortunately they're nice enough to post their quantcast data publicly: http://www.quantcast.com/p-19UtqE8ngoZbM http://www.quantcast.com/p-19UtqE8ngoZbM They're still phenomenal numbers, but IMHO should be much closer to a 100-server environment than a 1000 server one.

jonknee 15y ago
100 servers for billions of requests per day seems crazy optimistic. It sounds like they're running pretty lean as it is.
- NyxWulf 15y ago
  It all depends on the nature of the request. Our nginx servers are tuned to burst to 7000 requests/second and run stable at 4800 requests/second for simple content. Our overall scale is about 1/5th of what Tumblr is doing daily and we have a much smaller infrastructure footprint. Although in fairness our content is no where near as dynamic as theirs is.
- sanswork 15y ago
  I've done ~1b/day on around 6-10 1gb/gogrid instances though admittedly the complexity was lower(ad serving platform) though not just a proxy/static server. When I read this I actually messaged my partner "Imagine what we could do with 1000 servers". I imagine a lot of those servers aren't directly related to serving the site though. The number of support servers required is usually way underestimated.
  - encoderer 15y ago
    I think you're on to something when you contrast the 2 problem domains. Number of requests is a very naive way to look at load factors. At the startup I work, we've got 25-30 Million users, many stats similar to Tumblr, and we're running it on about 250 Ec2 instances of varying size. I think if Tumblr's numbers are high at all -- due to rapid iterations and no time to focus on deep optimizations -- it's maybe 10-15% high, not 90%. I'm saying this because I've seen periods where our usage numbers are somewhat flat, even falling, but our hardware demands rise as we provide more features. When there's just one or two primary ways to use a service (eg "I post status updates and comment on my friends' status updates") it can be quite easy to optimize. But add features. Photos. Chat. An in-house ad serving platform. I18N. Etc. You have different types of interactions with different acceptable service levels and varying storage requirements.
    - jaylevitt 15y ago
      Exactly. My iPhone can process 800 million requests per second. It's just that those requests are to add two integers. A request for static content != a request for dynamic content != a request for inter-user messaging != a request for a recommendation engine.

by cagenut 15y ago

jonknee 15y ago

100 servers for billions of requests per day seems crazy optimistic. It sounds like they're running pretty lean as it is.

NyxWulf 15y ago
It all depends on the nature of the request. Our nginx servers are tuned to burst to 7000 requests/second and run stable at 4800 requests/second for simple content. Our overall scale is about 1/5th of what Tumblr is doing daily and we have a much smaller infrastructure footprint. Although in fairness our content is no where near as dynamic as theirs is.
sanswork 15y ago
I've done ~1b/day on around 6-10 1gb/gogrid instances though admittedly the complexity was lower(ad serving platform) though not just a proxy/static server. When I read this I actually messaged my partner "Imagine what we could do with 1000 servers". I imagine a lot of those servers aren't directly related to serving the site though. The number of support servers required is usually way underestimated.
- encoderer 15y ago
  I think you're on to something when you contrast the 2 problem domains. Number of requests is a very naive way to look at load factors. At the startup I work, we've got 25-30 Million users, many stats similar to Tumblr, and we're running it on about 250 Ec2 instances of varying size. I think if Tumblr's numbers are high at all -- due to rapid iterations and no time to focus on deep optimizations -- it's maybe 10-15% high, not 90%. I'm saying this because I've seen periods where our usage numbers are somewhat flat, even falling, but our hardware demands rise as we provide more features. When there's just one or two primary ways to use a service (eg "I post status updates and comment on my friends' status updates") it can be quite easy to optimize. But add features. Photos. Chat. An in-house ad serving platform. I18N. Etc. You have different types of interactions with different acceptable service levels and varying storage requirements.
  - jaylevitt 15y ago
    Exactly. My iPhone can process 800 million requests per second. It's just that those requests are to add two integers. A request for static content != a request for dynamic content != a request for inter-user messaging != a request for a recommendation engine.