我认为问题并不在于Django的伸缩性。

我真的建议你研究一下你的架构，这将有助于你的扩展需求。如果你弄错了，Django的性能就没有意义了。性能=规模。你可以拥有一个具有惊人性能但无法扩展的系统，反之亦然。

您的应用程序是否绑定了数据库?如果是，那么你的规模问题也存在。你打算如何与Django中的数据库交互?如果数据库处理请求的速度不及Django接收请求的速度，会发生什么?当您的数据超出一台物理机器时会发生什么。你需要考虑如何应对这些情况。

此外，当你的流量超过一个应用服务器时会发生什么?在这种情况下，如何处理会话是很棘手的，通常情况下，您可能需要一个共享的“无”架构。这取决于你的应用。

简而言之，决定规模的不是语言，而是语言的性能(同样取决于您的应用程序，不同的语言表现不同)。正是您的设计和架构使扩展成为现实。

我希望它能有所帮助，如果你有问题，我很高兴能进一步帮助你。

下面是Django中构建的一些相对高调的东西:

《卫报》的“调查你的议员的开支”应用程序 Politifact.com(这里有一篇博客文章谈论了(积极的)体验。Site获得了普利策奖。 《纽约时报》的代表应用 EveryBlock WaPo的程序员之一Peter Harkins在他的博客上列出了他们用Django构建的所有东西 它有点老了，但是《洛杉矶时报》的人给出了他们为什么选择Django的基本概述。 洋葱的AV俱乐部最近从(我想是Drupal)转移到了Django。

我想很多这样的网站每天的点击率都超过了10万。Django当然可以达到10万/天甚至更多的点击量。但是YMMV的作用取决于你要建什么。

在Django级别有缓存选项(例如在memcached中缓存查询集和视图可以创造奇迹)和其他级别(如Squid这样的上游缓存)。数据库服务器规范也将是一个因素(通常是挥霍的地方)，以及您对它的调优情况。例如，不要想当然地认为Django会正确地建立索引。不要认为默认的PostgreSQL或MySQL配置就是正确的。

此外，如果Django运行速度慢，您总是可以选择让多个应用服务器运行Django，并在前面安装一个软件或硬件负载均衡器。

最后，静态内容和Django是在同一个服务器上提供的吗?你用的是Apache还是nginx或者lighttpd?你能负担得起为静态内容使用CDN吗?这些都是需要考虑的问题，但都是很有推测性的。每天10万点击量并不是唯一的变量:你想花多少钱?管理所有这些组件，您有多少专业知识?你有多少时间把这些都整理好?

问题是不知道django是否可以伸缩。

正确的方法是理解和知道哪些网络设计模式和工具应该放在django/symfony/rails项目下，以实现良好的扩展性。

一些想法可以是:

多路复用。 反向代理。例如:Nginx，清漆 Memcache会话。例如:Redis 在项目和数据库上进行集群化，以实现负载平衡和容错:例如:Docker 使用第三方存储资产。例子:Amazon S3

希望它能有所帮助。这是我的小石头。

我所知道的最大的django网站是华盛顿邮报，这肯定表明它可以很好地扩展。

好的设计决策对性能的影响可能比其他任何东西都要大。Twitter经常被认为是另一个基于动态解释语言的web框架——Ruby on Rails——体现了性能问题的站点——但Twitter工程师表示，该框架并不像他们早期所做的一些数据库设计选择那样是个大问题。

Django可以很好地使用memcached，并提供了一些管理缓存的类，这可以解决大部分性能问题。在现实中，你在网络上交付的东西几乎比你的后端更重要——使用像yslow这样的工具对于高性能web应用程序来说是至关重要的。你可以在后台添加更多硬件，但你不能改变你的用户带宽。

如果您的站点包含一些静态内容，那么在前面放置一个Varnish服务器将极大地提高您的性能。即使是一个盒子也能轻易产生100 Mbit/s的流量。

注意，对于动态内容，使用像Varnish这样的东西变得更加棘手。

我使用Django的经验很少，但我记得在Django书中有一章他们采访了运行一些大型Django应用程序的人。这里有一个链接。我想这能提供一些启示。

它说curse.com是最大的Django应用程序之一，每月有6000万到9000万的页面浏览量。