如果客户已经拥有 CDN 缓存，可以不启用 cache:true, cacheSize:xxx 。 这种内存缓存功能仅适用于没有生产就绪 CDN 的简单店面。也就是说，如果客户没有任何外部缓存服务（akamai / cloudflare / 其他），他们可以尝试，至少暂时，使用 SSR 服务内存缓存和 cache: true （最好也使用 cacheSize）。

concurrency 值设置得过大也不合适，这样会导致额外的性能下降。当太多请求同时命中一个 Pod 时，请求可能会超时。

我们引入了一个数组，用来记住 callbacks.

我们仅在渲染完成或 maxRenderTime 到达时清除数组。

如果单个 URL 的渲染任务花费大量时间（例如一分钟），则对该 URL 的所有请求显然都会超时。 但是我们将存储它们的回调直到 maxRenderTime 过去。 这意味着对于 1.5 分钟，数组可能会随着单个 URL 的增长而增长。 只有在 1.5 分钟后，我们才放弃并清除数组。 您可以同时渲染 50 个 URL。
我们可以在补丁中潜在地改进/优化：立即从数组中删除任何超时回调。 [由于所需额外重构的复杂性，我们决定不这样做]。
除此之外，根据流量，增加 Pod 中的内存限制可能会有所帮助。
此外，如果渲染任务真的（由于任何原因）“永远”挂起，无论如何都可能导致内存泄漏。

请注意 concurrency: 50（在 SsrOptimizationOptions 中）意味着 OptimizedSsrEngine 最多将执行 50 个并行渲染任务。
启用 reuseCurrentRendering，这意味着：一次最多可以渲染 50 个不同的 URL（不管并行请求的数量）。
这意味着：如果您一次发送 51 个或更多不同 URL 的并行请求，则第 51 个 URL（以及更多）的请求将立即回退到 CSR。 这是设计使然。

此外，如果您启用 debug:true，那么您将看到控制台消息 CSR fallback: Concurrency limit exceeded (edited)

一般来说，并发请求越多，无论是否缓存 OCC，平均响应越慢。

当 OCC 响应没有被缓存时，PDP 的 SSR 响应时间可能会有所不同，但当只有 1 个并发请求时，Maximum 甚至可以达到 7 秒。

与未缓存 OCC 时相比，缓存 OCC 时 SSR 响应时间平均快约 3 秒。

如果 OCC 未缓存，但使用静态基站配置而不是动态配置 - 平均响应时间更快，例如 从 1 到 15 个并发请求，我们使用静态 basesite 配置节省了 0.1-0.5 秒

理想情况下，如果可能，尽量避免 SSR 服务器过载。 相反，您应该在 SSR 之前设置一个带有缓存的 CDN。 并且您应该巧妙地对缓存进行部分预热，这样 SSR 服务器就不会因为所有预热请求而立即受到攻击。 缓存失效和重新预热也应该在某些部分巧妙地发生。

给 SSR 添加 OCC API 本地缓存用于测试的代码：

// global static reference - so it's shared among all rendered apps in SSR:
const CACHE = new Map<string, any>();

@Injectable()
export class CustomCacheInterceptor implements HttpInterceptor {

  intercept(
    request: HttpRequest<unknown>,
    next: HttpHandler
  ): Observable<HttpEvent<unknown>> {
    const { method, urlWithParams } = request;

    if (!['GET', 'HEAD'].includes(method)) {
      console.log('