I don't have doubts about Django scaling.
The caching framework is really cool. I did a test a couple of weeks ago, and I got a 10x performance boost, simply by sprinkling 3-4 lines of caching code to my site. That was justing the local memory caching: http://docs.djangoproject.com/en/1.0/topics/cache/#local-mem...
I'd imagine that using a caching back end like memcache would probably give another huge performance boost. It's really pretty straight-forward and usable out of the box.
I'm not disagreeing that scaling isn't only caching, but it's often a component just like anything else. Caching often helps scaling, as do multiple databases, working out bottlenecks in code...whatever else.
Caching is not scaling because by definition, it depends on a backend to provide it data.
If the backend is a database then sure, you can increase capacity by ~10x (assuming a ~90% cache hit rate), but after that, throwing more caching nodes at the problem won't do a thing if your database itself isn't scalable.
All a cache does is increase speed at decreased costs, but it is not in itself a scaling solution.
Signed, the guy who introduced Django to washingtonpost.com
Are there any issues in particular you're concerned about?
For example, did you modify the source to support multiple databases for read/write? Or is that not an issue and it's OK that it's coming later in the framework's roadmap?
Discussing this before starting a startup sort of feels like trying to figure out how to do salary for hundreds of employees before getting your first one.
* squid reverse proxies
* memcached
* low memory footprint httpd serving static content (e.g. nginx / lighttpd etc.)Thanks for the resource. This will come in handy.