2021-10-28 SAP Spartacus SSR 性能方面的一些学习笔记

如果客户已经拥有 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('
上一篇:使用香浓熵实现DNS Tunnel检测


下一篇:SAP Spartacus 和 SmartEdit 集成的一些 bug:2021-6-29