NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Scaling Django to 8 Billion Page Views: What is slow

On the surface, the first impression is that a web framework is slow because there is a lot of boiler plate and unnecessary code that is not needed for your application, and that is a valid impression. In practice, slowness is usually not a product of your framework’s bloat or the language choice. Slowness is likely a result of the fact that your request is communicating with other services across your network. In our case, these other services are PostgreSQL, Redis, Cassandra, and Memcached, just to name a few. Slow database queries and network latency generally outweigh the performance overhead of a robust framework such as Django.

The correct way to read this is that even if you can super-optimize your app layer, focusing on network communications will probably yield better results. We usually hear that the database is the bottleneck. That’s true if it means that we are asking the database to do too much and/or too many times. I sometimes wonder how many web pages out there still do tens of queries per request, involving chained JOINs (“thanks” to magical ORMs), and filtering out the final results on the client side, after initializing tons of objects.

Original title and link: Scaling Django to 8 Billion Page Views: What is slow (NoSQL database©myNoSQL)