search

vuestorefront / vue-storefront-1

The open-source frontend for any eCommerce. Built with a PWA and headless approach, using a modern JS stack. We have custom integrations with Magento, commercetools, Shopware and Shopify and total coverage is just a matter of time. The API approach also allows you to merge VSF with any third-party tool like CMS, payment gateways or analytics. Newest updates: https://blog.vuestorefront.io. Always Open Source, MIT license.
https://www.vuestorefront.io
MIT License
19 stars 13 forks source link

Massive delay in serving cached content #116

Closed bloodf closed 3 years ago

bloodf commented 3 years ago

From vue-storefront created by lukeromanowicz: vuestorefront/vue-storefront#4125

Current behavior

There is a 90-150ms delay between connection and serving cache from content present on stock vue storefront. Express is capable of responding with less than 1ms TTFB so it looks like some issue with VSF codebase.

image

Expected behavior

serving cached content in 20-50ms, not 200ms+

Steps to reproduce the issue

  1. enable redis cache in frontend
  2. test ttfb on a cached page

Can you handle fixing this bug by yourself?

Which Release Cycle state this refers to? Info for developer.

Pick one option.

bloodf commented 3 years ago

@lukeromanowicz @cewald guys maybe we should create a set of tasks based on this one? I mean it's kind of epic. There is no single solution as it depends on multiple factors relative to the prod. env mostly

wdyt?

bloodf commented 3 years ago

Good point. Is this result from your local instance/storefrontcloud/other?

One of the solutions is this: https://github.com/ClickAndMortar/docker/tree/master/vue-storefront/proxy/lua (it will be automatically deployed to all SC instances soon, currently tested in Zadig&Voltaire - developed by these folks).

There could be many reasons for this delay; if it’s On the cloud we already have some findings with @mkoszut so we can share - usually it’s related to the pm2 process saturation / event loop caused by the other requests (eg. image resize)

bloodf commented 3 years ago

It's partially dependent on NodeJS version. Using Node 13 instead of Node 10 made about 30% improvement. That being said it's still a case both on demo cloud and my local environment. I know for a fact though that @ResuBaka is not experiencing this issue on his Arch-based setup.

bloodf commented 3 years ago

@pkarw In our case I refactored the connector for our CMS inside the API that makes HTTP requests to external services (Storyblok CMS) using the http2-client node library. It's not as convenient as node-request or axios but you're able to use the benefits of HTTP2.

bloodf commented 3 years ago

Somehow related: #4089 Related to: #4096, #4094

bloodf commented 3 years ago

I can give here some info from my debugging.

Nodejs 10 Google Cloud NB2 n2d-standard-2 Ubunut 18LTS Kernel 5.0: Has the problem Kernel 5.5: Has the problem Centos8: Has the problem

All had nearly the same times +/-5ms, but over all +100ms from when the cache function sends the request and the TTFB happens.

The problem looks like a delay when nodejs sends the request to the operation system and the response of it.

As the cache time and the reg.on('finish') call take the same time ~44ms and after that the ttfb is ~120ms.

That sad locally on my Manjaro setup I don't have that problem and on the System of one of my Coworkers (Ubuntu 18LTS) the problem is not there same behavior as for me.

My timings locally with node 10 or node 13 are cache time 13ms und reg.on('finish') 13ms and a ttfb of 25ms.

On all the systems the redis was on the local system and the curl command was curl -D - --output /dev/null -H 'Cache-Control: no-cache' -s -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" http://localhost:3000.

For me it looks like some config settings of the Linux Setup, but there I have not looked into it if there are some network stack setup that may could cause this issue.

I hope these info helps when some body else is looking into this issue.

bloodf commented 3 years ago

I noticed that it makes a huge different if I send a server-side request, using HTTP1 or HTTP2. Especially in the vue-storefront-api. This might be a bit off-topic and maybe not directly connected to the problem above – but as I tried to trace down where this latency came from, I saw that all common request libs like axios, node-fetch or node-request do not support HTTP2 – so I tried it by implementing it using the nodejs' native HttpRequest class, and it was noticeable faster, especially for large responses. So – it could bring an improvement of TTFB when a request is made on the server-side during the request.

bloodf commented 3 years ago

That's interesting observation @cewald any ideas how to fix it?