Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize request handling #166

Open
marvinhagemeister opened this issue Oct 19, 2020 · 3 comments
Open

Optimize request handling #166

marvinhagemeister opened this issue Oct 19, 2020 · 3 comments

Comments

@marvinhagemeister
Copy link
Member

@andrewiggins pointed us to this tweet which points to a benchmark of dev mode for bundlers. It's a project with 3k components.

https://github.com/kenotron/scale-test

Tried it with wmr and we run into the same problems. Fullfilling all 3k requests takes about 20s and nearly all of them are stalled due to the browser's limit on handling parallel requests.

Screenshot 2020-10-19 at 08 30 37

Can't get results via our --http2 flag as the certificate authority fails on MacOS for me.

@developit
Copy link
Member

I think my numbers are around 20s cold, 10s warm. This is very exactly the worst-case setup for WMR though: it's typescript with JSX, so we pass modules through both Sucrase and Acorn, and all modules are 1kb so they get parsed synchronously by the browser.

@marvinhagemeister
Copy link
Member Author

Pasting our thoughts from slack earlier today on what we could do to improve performance:

  • Pre-fill cache immediately on boot. There's a small enough window were we can do transformations pro-actively, especially with TS like in the test
  • Use a strong cache up-front that is only invalidated by watching changes
    • We currently do duplicated work: The same modules will be resolved + transformed every time it is requested, not when something changed
@developit
Copy link
Member

developit commented Oct 28, 2020

Update from me: we should re-test this with the dev-time SSR from #169, since it provides all of the page's modules as flat <script> tags. It's not a full solution since the waterfall happens on the server, but it's likely considerably faster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants