# 从 HackerEarth 用 Apache 扩展 Python 和 Django 的 13 个简单技巧 > 原文： [http://highscalability.com/blog/2014/2/10/13-simple-tricks-for-scaling-python-and-django-with-apache-f.html](http://highscalability.com/blog/2014/2/10/13-simple-tricks-for-scaling-python-and-django-with-apache-f.html)  [HackerEarth](http://www.hackerearth.com/) 是一项编码技能实践和测试服务，在一系列写得很好的文章中描述了构建站点的试验和磨难，以及它们如何克服它们：[使用以下方法扩展 Python / Django 应用程序： Apache 和 mod_wsgi](http://engineering.hackerearth.com/2013/11/21/scaling-python-django-application-apache-mod_wsgi/) ，[编程方面的挑战，正常运行时间和错误（2013 年）](http://engineering.hackerearth.com/2014/01/22/programming-challenges-uptime-mistakes/)，P [ ost-mortem：2014 年 1 月 25 日的大故障](http://engineering.hackerearth.com/2014/01/27/big-outage-25-january/)，[强大的实时服务器](http://engineering.hackerearth.com/2013/05/31/the-robust-realtime-server/) ， [100,000 个强大的 CodeFactory 服务器](http://engineering.hackerearth.com/2013/03/12/100000-strong/)，[具有 Django 和 HAProxy 的扩展数据库](http://engineering.hackerearth.com/2013/10/07/scaling-database-with-django-and-haproxy/)，[连续部署系统](http://engineering.hackerearth.com/2013/08/05/continuous-deployment-system/)， [HackerEarth 技术堆栈](http://engineering.hackerearth.com/2013/03/20/hackerearth-technology-stack/)。 这些文章的特征并使其特别有用，是对改进的驱动力和对报告哪些无效以及如何确定哪些有效的开放态度。 正如他们所说的那样，当您仅由 3-4 名工程师组成的团队来构建复杂的产品时，就会发生错误，但是对基础架构的投资使他们可以进行更多的休息，在班加罗尔的街道上漫游，而他们的服务器每分钟很高兴地为成千上万的请求提供服务 ，同时轻松达到 50,000 个用户群。 这是他们做事的方式： **HackerEarth 的当前体系结构：**前端服务器； API 服务器； 代码检查器服务器； 搜索服务器-Apache Solr &弹性搜索； 实时服务器-使用 Tornado 编写； 状态服务器； 工具链服务器（主要用于持续部署）； 集成测试服务器； 日志服务器； Memcached 服务器； 很少有服务器可以处理数据分析数据库和后台作业。 RabbitMQ，Celery 等粘合许多服务器； 监控服务器； 数据库经过分片并通过 HAProxy 进行负载平衡。 1. **删除不必要的 Apache 模块**。 节省内存并提高性能。 通过只包含您需要的内容，您可以将加载的模块数量减少一半。 2. **使用 Apache MPM（多处理模块）工作者**。 通常，对于高流量服务器来说，这是一个更好的选择，因为它比前叉 MPM 占用的内存少。 3. **保持活动状态**。 CloudFront 提供了静态文件，实验表明，这样做效率更高，进程/线程可以自由地即时处理新请求，而不必等待请求到达较旧的连接。 4. **mod_wsgi** 的守护程序模式。 线程和进程的数量是恒定的，这可以使资源消耗可预测，并防止流量高峰。 5. **调整 mpm-worker 配置**。 他们在经过大量试验后显示了他们使用的配置，这有利于他们的应用程序类型，这种类型的应用程序比 CPU 占用更多的内存。 6. **检查配置**。 启用模块 mod_status.so 和 mod_info.so 以查看 Apache 的运行方式。 这些信息帮助他们大大减少了我们必须运行的服务器数量，并使应用程序更稳定，更能抵抗流量突发。 7. **不会自动缩放**。 100％的正常运行时间是不断的斗争。 卷起袖子，朝着这个目标努力。 8. **不要为运行 100 台服务器**而感到自豪。 编写更好的代码并调整系统。 向大量请求抛出服务器并不引以为豪。 例如，这意味着确保请求不会查询数据库 20 次。 9. **异步代码检查器服务器排队系统**。 重写代码检查器服务器排队系统以使其异步，从而大大减少了其前端服务器上的处理开销。 10. **使用龙卷风进行认真的平行作业**。 “ socket.io”模块无法扩展到超过 150 个同时连接。 Nowjs 还泄漏了文件描述符。 11. **分片数据库和数据库路由器**。 对数据库进行分片可减少单个数据库的开销，并进一步减少查询延迟。 12. **缓存它**。 在内存缓存中有超过一百万个键值对，会话以 redis 维护，其他任何持久性数据都进入 MySQL 或 S3，但是大多数缓存都保留了适当的生命周期。 13. **持续部署**。 手动更新生产中的代码更改会使他们发疯，这将完全浪费时间。 我实际上很喜欢这篇文章，但是请不要开始使用链接诱饵标题。 我通常会忽略带有此类标题的内容，直到我意识到它具有高可伸缩性，我几乎跳过了这一标题。 确实。 这不是一些愚蠢的嗡嗡声。这些文章的内容并不保证会被贬低为“＃X 的简单技巧”标题。 实际上，我尝试了各种各样的内容。 有些长，有些短。 一些原始的，一些其他的。 如果您感兴趣的话，有些则精心策划了其他细节，有些则是独立的。 有些是针对初学者的，有些是针对专家的。 一些非常具体，一些非常笼统。 因此，任何一篇帖子都可能不是您的事，但这并不意味着它不会成为某人的事。 项目符号格式是传达特定想法的最快方法。 这些想法可能对许多人来说都是旧帽子，或者是新的有趣的东西。 如果有兴趣，您可以参阅参考的源材料以获取更多详细信息，这正是这个主意。 否则，您可以继续前进，这确实是个主意。 我认为前两个评论仅表示他们不喜欢标题，因为它看起来像是个骗人的把戏。 但正如他们也指出的那样，您的文章始终都是出色的，这就是为什么继续阅读它的原因。 确实，内容没有问题。 只是 linkbait 的头衔（不公正地）。 jpj，完全是。 :)