DRF - PrimaryKeyRelatedField 的可浏览界面非常慢答案

【问题标题】：DRF - browsable interface very slow with PrimaryKeyRelatedFieldDRF - PrimaryKeyRelatedField 的可浏览界面非常慢
【发布时间】：2016-02-07 07:18:13
【问题描述】：

如何使用 RelatedField 使 Django Rest Frameworks 可浏览 UI 快速？

我知道这里已经有人问过这个问题：Django REST Framework: slow browsable UI because of large related table，但答案对于新版本的 DRF 不再有效

包含两个 PrimaryKeyRelatedFields 给我 5 秒以上的加载时间，删除它们让我回到 0.3 以下

我尝试设置html_cutoff=100 甚至html_cutoff=1，但加载时间似乎没有区别。

有什么想法吗？目前在 DRF '3.3.2'

编辑：涉及的表有 12000 到 120 条记录 - 但处理更多的记录会很棒

【问题讨论】：

不妨确认一下：当您将它作为 JSON 检索时它仍然很慢还是只影响可浏览的 API？
纯 JSON 很好。对不起，我应该在问题中这么说。请参阅下面的“答案” - 这是一个已知问题，有几个 PR 可以通过不同方式解决它

标签： django performance user-interface django-rest-framework browsable

【解决方案1】：

由于 DRF 版本 3.4.4，可以使用 selected fields cutoffs 限制显示的关系数量。

来自 DRF 文档：

在可浏览的 API 关系字段中呈现时，将默认仅显示最多 1000 个可选项目。如果存在更多项目，则会显示“超过 1000 个项目...”的禁用选项。

...

您还可以使用 HTML_SELECT_CUTOFF 和 HTML_SELECT_CUTOFF_TEXT 设置全局控制这些。

【讨论】：

【解决方案2】：

此问题与Django REST Framework: slow browsable UI because of large related table 类似或重复。

本质上是 N+1 问题，在 Django 的上下文中，可以通过调用 prefetch_related() 或 QuerySet 上的 prefetch_related() 或 select_related() 预先加载数据来修复它。检查这个answare

【讨论】：

嘿，感谢您回答这个老问题。我实际上在我的问题中链接到那个问题。我已将我的答案标记为正确，并评论了一个指向解决我的问题的 PR 的链接，但对你的答案表示赞同。

【解决方案3】：

不是我正在寻找的答案，但目前看起来 github 上已经有相关活动 - https://github.com/tomchristie/django-rest-framework/issues/3329 运气好的话，其中一个补丁将很快合并

【讨论】：