Test scenario 1：SSR cache option not activated, low concurrency

SSR optimization engine setting：Meter setting：sending 10 requests for the same page simultaneously

Test result:

The 9 requests get CSR fallback result;

The last request gets SSR result

————————————————

版权声明：本文为CSDN博主「汪子熙」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/i042416/article/details/119909727CSR fallback observed in the backend:Test scenario 2：SSR cache option activated, low concurrencyWhen I send the first group of 10 requests, the same test result as Scenario 1.

And when I send the second group of 10 requests, all those 10 results are served by cached SSR result.

Test scenario 3：SSR cache option not activated, high concurrency

SSR Optimization engine:Test result: the same as scenario 1.Test scenario 4：SSR cache option activated, high concurrency

SSR Optimization engine:est scenario 5：SSR cache option activated, high concurrency, enlarge timeout value

SSR optimization engine:Conclusion

When a lot of requests for the same page reach SSR server simultaneously, only the request which picked up first by SSR server ( let’s call it request A) can succeed SSR process, all other requests will fall back CSR due to the rendering flag in SSR Optimization engine.

Enlarging timeout or maxRenderTime value will NOT change above behavior.

If cache option is applied, the situation could be mitigated to some degree, that is, as long as one request is finished by SSR successfully, all other subsequent request on the same page could be directly served by cached result ( see scenario 2,4,5)