导读：今天首席CTO笔记来给各位分享关于django并发的优化有哪些的相关内容，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
django自带的开发服务器能同时支持多少人在线
django自带的那个是效率相当低下的，它没有采用epoll/kqueue。
具体支持多少人在线，这个很难说。
测了一下，对于我的电脑，初始django工程的根的并发能力大概是294。
相比而言，tornado是高性能的server，用它文档的web的范例，并发能力大概是1324。
对nginx上的一个只包含“hello world!"的静态文件的访问，并发能力大概是2942
[Django] celery的替代品 funboost
Django开发web应用的过程中，一个老大难问题是异步调度问题。例如用户传来一个非常耗时的请求，这时候最好的处理方式是先把这个操作请求记录下来，先响应请求，等后面有空的时候再去计算，而不是让用户干等着着急。
这种优化方式就是典型的生产者+消息队列+消费者设计模式，而Django框架本身并没有直接提供该设计模式的实现，大多教程都是利用第三方组件celery+redis来实现这个调度。
遗憾的是celery和redis官方都不支持windows，而我习惯的开发环境还是win10，所以需要找一个替代品。经过调研，发现了一个很好的【python分布式函数调度框架——funboost】. 它的优点很多，对Django开发来说，最大的亮点是完全无需启动第三方服务，即可实现生产消费设计模式。一个 pip install funboost 即可干活，开箱即用。它可以使用SQLite文件来做消息队列，足以应对小型应用开发。当然也可以使用Kafka这种高级的消息中间件，实现高可用。
要说缺点吧，这个组件的日志打印太啰嗦，而且没有提供关闭选项，控制台已被它刷屏。
如何优化 Django REST Framework 的性能
解决 Django 「懒惰」的基本方法
现在我们解决这个问题的方法就是「预加载」。从本质上讲，就是你提前警告 Django ORM 你要一遍又一遍的告诉它同样无聊的指令。在上面的例子中，在 DRF 开始获取前很简单地加上这句话就搞定了：
queryset = queryset.prefetch_related('orders')
当 DRF 调用上述相同序列化 customers 时，出现的是这种情况：
获取所有 customers （执行两个往返数据库操作，第一个是获取 customers，第二个获取相关 customers 的所有相关的 orders。）
对于第一个返回的 customers，获取其 order （不需要访问数据库，我们已经在上一步中获取了所需要的数据）
对于第二个返回的 customers，获取其 order （不需要访问数据库）
对于第三个返回的 customers，获取其 order （不需要访问数据库）
对于第四个返回的 customers，获取其 order （不需要访问数据库）
对于第五个返回的 customers，获取其 order （不需要访问数据库）
对于第六个返回的 customers，获取其 order （不需要访问数据库）
你又意识到，你可以有了 很多 customers ，已经不需要再继续等待去数据库。
其实 Django ORM 的「预备」是在第1步进行请求，它在本地高速缓存的数据能够提供步骤2+所要求的数据。与之前往返数据库相比从本地缓存数据中读取数据基本上是瞬时的，所以我们在有很多 customers 时就获得了巨大的性能加速。
解决 Django REST Framework 性能问题的标准化模式
我们已经确定了一个优化 Django REST Framework 性能问题的通用模式，那就是每当序列化查询嵌套字段时，我们就添加一个新的 @staticmethod 名叫 setup_eager_loading ，像这样：
class CustomerSerializer(serializers.ModelSerializer):
orders = OrderSerializer(many=True, read_only=True)
def setup_eager_loading(cls, queryset):
""" Perform necessary eager loading of data. """
queryset = queryset.prefetch_related('orders')
return queryset
这样，不管哪里要用到这个序列化，都只需在调用序列化前简单调用 setup_eager_loading ，就像这样：
customer_qs = Customers.objects.all()
customer_qs = CustomerSerializer.setup_eager_loading(customer_qs) # Set up eager loading to avoid N+1 selects
post_data = CustomerSerializer(customer_qs, many=True).data
或者，如果你有一个 APIView 或 ViewSet ，你可以在 get_queryset 方法里调用 setup_eager_loading ：
def get_queryset(self):
queryset = Customers.objects.all()
# Set up eager loading to avoid N+1 selects
queryset = self.get_serializer_class().setup_eager_loading(queryset)
return queryset
如何在Django模型中管理并发性
1、我们在我们的查询器上使用select_for_update来告诉数据库锁定对象，直到事务完成。
2、在数据库中锁定一行需要一个数据库事务 - 我们使用Django的装饰器transaction.atomic来定义事务。
3、我们使用类方法而不是实例方法 - 我们告诉数据库要上锁，然后它会返回锁的对象给我们。 为了实现这一点，我们需要从数据库中获取对象。 如果我们使用self，那么就是在操作一个已经从数据库中获取出来的对象，这个对象无法保证自己是没有被上锁的。
4、帐户中的所有操作都在数据库事务中执行。
[Django]Admin中inlines的优化（二）
在 [Django]Admin中inlines的优化 中，介绍了一些优化策略，这里补充两点。
Django程序在接收到GET/POST请求时，会检查请求参数的个数是否超过 DATA_UPLOAD_MAX_NUMBER_FIELDS 。如果请求参数个数超过这个值，该请求被认定为恶意请求，程序抛出异常。该值默认为1000. 如果Django程序中，admin内的inline行数很多，那么很容易超出这个值。此时，用户将无法完成数据上传。此时可以调大 DATA_UPLOAD_MAX_NUMBER_FIELDS ，或者令 DATA_UPLOAD_MAX_NUMBER_FIELDS = None ，取消这个异常检查。
顾名思义， django-admin-inline-paginator 插件能够为inline分页。这样，不用一次加载过多数据，有效的避免了inline过多带来的系统负担，非常推荐初学者使用。
🍅 3
💪 0
python高并发web框架有哪些
python的web框架很多
django (大而全，模板，orm都自带)
flask (pocoo出品，比属精品，自带jinja2模板，可以替换)
web.py (这个我没用过，作者自杀，白瞎了一个高手)
bottle (只有一个文件的框架，需要自己构建整个开发体系)
uliweb (中国人开发的，也很不错)
Tornado (异步框架，适合长连接，比如在线聊天之类的)
Python框架虽然说是百花齐放，但仍然有那么一家是最大的，它就是Django。Django为人所称道的地方主要有：
①完美的文档，Django的成功，我觉得很大一部分原因要归功于Django近乎完美的官方文档（包括Django book）。
②全套的解决方案，Django象Rails一样，提供全套的解决方案（full-stack framework + batteries included），基本要什么有什么（比如：cache、session、feed、orm、geo、auth），而且全部Django自己造，开发网 站应手的工具Django基本都给你做好了，因此开发效率是不用说的，出了问题也算好找，不在你的代码里就在Django的源码里。
③强大的URL路由配置，Django让你可以设计出非常优雅的URL，在Django里你基本可以跟丑陋的GET参数说拜拜。
④自助管理后台，admin interface是Django里比较吸引眼球的一项contrib，让你几乎不用写一行代码就拥有一个完整的后台管理界面。
结语：以上就是首席CTO笔记为大家介绍的关于django并发的优化有哪些的全部内容了，希望对大家有所帮助，如果你还想了解更多这方面的信息，记得收藏关注本站。
以上内容为新媒号(sinv.com.cn)为大家提供！新媒号，坚持更新大家所需的互联网后端知识。希望您喜欢！
版权申明：新媒号所有作品（图文、音视频）均由用户自行上传分享，仅供网友学习交流，不声明或保证其内容的正确性，如发现本站有涉嫌抄袭侵权/违法违规的内容。请发送邮件至 k2#88.com(替换@) 举报，一经查实，本站将立刻删除。
