Skip to content

Comment on How a 1-Engineer Rails Site Scaled to 10 Million Requests Per Dayparent

Comments

Your methodology doesn't reflect actual usage of the site. I suspect there hardly an (if any) writes happening when you hit /users, the database is repeatedly fetching a hot query (or you are pulling from a cache that isn't changing because there are no writes happening), your dataset could be minimal, etc.

That may be partially true[1], but I'd challenge you to re-implement this non-optimized case (ie, this is a rough webapp, no caching, etc) in another runtime on similar hardware and see:

1) Whether it can support anywhere near the same level of concurrent requests with similar response times.

2) How much complexity (nginx + unicorn + memcached + puppies) is required to achieve this in comparison to a servlet engine (eg, tomcat) and your webapp.

[1] Most web applications are read-heavy, low on writes, and scaling up write capability generally requires scaling up the database. You can grow quite a bit with simple caching and monolithic database scaling before having to tackle more complex distributed data architectures.

If those 1968.41 [#/sec] were on a quad core then python can match it.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.