文档/安全与部署

性能

nx start 默认执行什么操作、打开什么以及测量什么。

默认值

nexyconfig.py中的表和页中的ISR的两个开关：

from nexy.core.models import NexyConfigModel  class NexyConfig(NexyConfigModel):    useGZip = {"minimum_size": 1000}    useDocs = False

---revalidate = 60---<h1>Rendered at most once per minute</h1>

测量的

本地运行，一个 Uvicorn 工作线程，Windows，Python 3.13，来自同一计算机上的 Python 负载生成器的保持活动连接。将这些数字视为比较变化的基线，而不是作为其他框架的基准。

表的 Nexy JSON 路由是这个文件：

async def GET():    return {"ok": True}

from nexy.decorators import Controller  @Controller("/api/ping")class PingController:    async def get(self):        return {"ok": True}

读表：

• Nexy 自己的层（路径上下文、中间件）消耗的吞吐量约为裸 FastAPI 路由的三分之一。
• 服务器渲染的页面大约需要 2 毫秒的 CPU 时间，分布在大约 16 个模板渲染上（每个组件一个）。组件较少的页面相应地更便宜。
• 吞吐量随工人而变化。在 Linux 上，nx start 已经为每个 CPU 启动一个。

实用建议

1. 将 Nginx、Caddy 或您平台的优势放在前面：TLS、HTTP/2、Brotli 和 /__nexy__/client/ 资产的长期缓存是它们的优势。请参阅部署。
2. 对于每分钟更改次数少于一次的页面，请使用 ISR。
3. 使用岛屿 懒惰地水合，因此第一批货物运输较少 JavaScript。
4. 保持每页的 .nexy 组件数量合理：每个组件都是一个单独的模板渲染。
5. 测量自己的路线。保持连接活动的本地负载生成器足以比较页面的两个版本。

Nginx 的建议 1：散列客户端包缓存一年，其余的交给 Nexy。

server {    listen 443 ssl http2;    server_name example.com;     location /__nexy__/client/ {        proxy_pass http://127.0.0.1:3000;        add_header Cache-Control "public, max-age=31536000, immutable";    }     location / {        proxy_pass http://127.0.0.1:3000;        proxy_set_header Host $host;        proxy_set_header X-Forwarded-Proto $scheme;    }}

后续步骤

• 部署
• 渲染
• 配置

以 Markdown 复制本页 在 GitHub 上编辑