4 ms·

I wrote a simple service in Go that takes <11MB RAM and can handle 7500 requests/sec. That was a fast one-off when playing around. I've never had even a simple

by trebor 13y ago

I wrote a simple service in Go that takes <11MB RAM and can handle 7500 requests/sec. That was a fast one-off when playing around. I've never had even a simple Sinatra app run half that fast.

Terretta 13y ago
More miscellaneous anecdata: In 2002, our Layer 7 streaming traffic redirector written in C, running on an old generic P3 800 CPU with 512 MB RAM, easily handled 15,000 requests per second of real world (unpredictable latency and error rates) HTTP and RTSP traffic. The service wasn't simple. It maintained a content map of all CDN files across layers of storage, servers, and cache, health of all server pools, and a geo IP database, and balanced users according to load optimization algorithms taking all these into account. The redirector and session mapping cache took <80MB RAM, with the rest devoted to async content promotion and demotion service, async geo IP service, async server health service, etc. Two points: (1) interpreted and heavy scaffolding framework Rails vs. hand coded Go doesn't tell us much we don't already know: that layers of abstraction and scaffolding can simplify development but slow execution, and (2) many of the requests per second benchmarks these days mostly illustrate that frameworks in general are wastefully slow, requiring far too much investment in hardware to scale. With one or two servers, this doesn't matter. Frameworks are invaluable for rapid iteration towards MVP proof, and fantastic for churning out web apps for mid tier companies with moderate (less than millions) traffic. But if you're going bigger, have a plan to get your bottlenecks closer to the metal, because with hundreds or thousands of servers, the savings becomes significant and possibly even crucial to your survival if your type of offering gets commoditized.

4 ms·

I wrote a simple service in Go that takes <11MB RAM and can handle 7500 requests/sec. That was a fast one-off when playing around. I've never had even a simple

by trebor 13y ago

I wrote a simple service in Go that takes <11MB RAM and can handle 7500 requests/sec. That was a fast one-off when playing around. I've never had even a simple Sinatra app run half that fast.

Terretta 13y ago
More miscellaneous anecdata: In 2002, our Layer 7 streaming traffic redirector written in C, running on an old generic P3 800 CPU with 512 MB RAM, easily handled 15,000 requests per second of real world (unpredictable latency and error rates) HTTP and RTSP traffic. The service wasn't simple. It maintained a content map of all CDN files across layers of storage, servers, and cache, health of all server pools, and a geo IP database, and balanced users according to load optimization algorithms taking all these into account. The redirector and session mapping cache took <80MB RAM, with the rest devoted to async content promotion and demotion service, async geo IP service, async server health service, etc. Two points: (1) interpreted and heavy scaffolding framework Rails vs. hand coded Go doesn't tell us much we don't already know: that layers of abstraction and scaffolding can simplify development but slow execution, and (2) many of the requests per second benchmarks these days mostly illustrate that frameworks in general are wastefully slow, requiring far too much investment in hardware to scale. With one or two servers, this doesn't matter. Frameworks are invaluable for rapid iteration towards MVP proof, and fantastic for churning out web apps for mid tier companies with moderate (less than millions) traffic. But if you're going bigger, have a plan to get your bottlenecks closer to the metal, because with hundreds or thousands of servers, the savings becomes significant and possibly even crucial to your survival if your type of offering gets commoditized.