我正在用Django构建一个web应用程序。我选择Django的原因是:
我想使用免费/开源工具。 我喜欢Python，觉得它是一种长期的语言，而对于Ruby，我不确定，而PHP似乎是一个巨大的麻烦。 我正在为一个想法构建一个原型，并没有过多地考虑未来。开发速度是主要因素，而且我已经了解Python。 我知道迁移到谷歌应用程序引擎将更容易，如果我选择这样做在未来。 我听说Django很“不错”。
现在我越来越接近于考虑出版我的作品，我开始担心规模问题。我找到的关于Django伸缩能力的唯一信息是Django团队提供的(我不是说什么要忽略它们，但这显然不是客观的信息…)
我的问题:
目前在Django上构建的“最大”站点是什么?(我主要通过用户流量来衡量规模) Django能每天处理10万名用户，每个用户访问站点几个小时吗? 像Stack Overflow这样的站点可以在Django上运行吗?
当前回答
我使用Django的经验很少，但我记得在Django书中有一章他们采访了运行一些大型Django应用程序的人。这里有一个链接。我想这能提供一些启示。
它说curse.com是最大的Django应用程序之一，每月有6000万到9000万的页面浏览量。
其他回答
下面是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书中有一章他们采访了运行一些大型Django应用程序的人。这里有一个链接。我想这能提供一些启示。
它说curse.com是最大的Django应用程序之一，每月有6000万到9000万的页面浏览量。
是的，它可以。它可以是Django with Python或Ruby on Rails。它仍然会缩放。
有几种不同的技术。首先，缓存不是可伸缩性。除了硬件平衡器之外，还可以有多个应用服务器以nginx作为前端平衡。 为了在数据库端扩展，如果你走RDBMS的路，你可以在MySQL / PostgreSQL中使用读从。
Django中一些大流量网站的例子如下:
当他们还在那里的时候。 通用共享评论管理器 所有与报纸相关的网站:《华盛顿邮报》等。
你会有安全感。
正如在高性能Django书中所述 然后查一下卡尔·亨德森
详情如下:
人们经常会说“Django无法伸缩”。这取决于你如何看待它，这种说法要么完全正确，要么明显错误。Django本身是无法伸缩的。
Ruby on Rails、Flask、PHP或数据库驱动动态网站使用的任何其他语言也是如此。
不过，好消息是Django与缓存和缓存套件的交互非常漂亮 负载平衡工具将允许它扩展到尽可能多的流量，你可以扔在它。
与你在网上看到的相反， 它可以做到这一点，而不需要替换通常被标记为“太慢”的核心组件，如数据库ORM或模板层。
Disqus每月的页面浏览量超过80亿次。这些都是很大的数字。
这些团队已经证明了Django的扩展性。 我们在林肯环线的经验证明了这一点。
我们已经建立了大型的Django站点，可以让用户在Reddit主页上轻松浏览一整天。
Django在伸缩方面的成功案例不胜枚举。
它支持Disqus、Instagram和Pinterest。想要更多的证据吗?只用3个工程师(其中2个没有后端开发)，Instagram就能在Django上维持超过3000万的用户
我们正在进行负载测试。我们认为我们可以支持240个并发请求(24x7每秒120次的持续速率)，而不会显著降低服务器性能。那就是每小时432000次点击。响应时间并不小(我们的事务很大)，但随着负载的增加，基线性能没有下降。
我们使用Apache前端Django和MySQL。操作系统为Red Hat Enterprise Linux (RHEL)。64位。我们在Django的守护模式下使用mod_wsgi。除了接受默认值外，我们没有做任何缓存或数据库优化。
我们都在一台64位戴尔的虚拟机中，(我想)有32Gb内存。
因为对于20或200个并发用户来说，性能几乎是相同的，所以我们不需要花费大量时间进行“调整”。相反，我们只需要通过普通的SSL性能改进、普通的数据库设计和实现(索引等)、普通的防火墙性能改进等来保持我们的基础性能。
我们测量的是我们的负载测试笔记本电脑在15个进程运行16个并发请求线程的疯狂工作负载下挣扎。
