Closed tbeseda closed 3 years ago
Documenting my attempt to inspect an Architect process:
Running the app with node --inspect node_modules/@architect/sandbox/bin/binary-entry.js
I was able to use the Chrome inspector to capture a curl request to /docs/en/guides/developer-experience/custom-source-paths
as a test.
The video shows a timeline with 2 spikes. I think these are the start and end of the actual work in the handler.
I zoom into the start to show that invokeLambda
runs and a child process is spawned. I think I'm unable to inspect that new Node process without messing with Arc internals.
edit: my initial description isn't clear. I think the gap between the spikes is when the handler is actually running in another process. So I can't see it.
I'm looking at other ways to profile the actual handler, just wanted to leave a trail
https://user-images.githubusercontent.com/15697/139151652-bdf40d84-ff35-4b98-9e57-9b3dac7b0319.mp4
Using shiki to do syntax highlighting seems to make the function run 10x slower than when it it is turned off.
Running locally:
Node.js execution times (24 code blocks): return doc: 251.424ms // with shiki return doc: 19.281ms // without shiki
Typescript (1 code block): return doc: 107.776ms // with shiki return doc: 8.773ms // without shiki
I reverted my local back to when we were using hljs and loading that Node.js page with a ton of code blocks is sub 40ms.
Any indication of incorrect implementation? Might be good to take a look. Not me, since I implemented it 😬
Things to try: default theme, less languages, no languages, without the custom Arc grammar. Something weird might fall out, like just adding the Ruby lang to Shiki's highlighter bogs it down.
It's not the languages, it's the parsing that seems to be slow. For example if I parse the node.js page it takes 255.835ms but if I take out all languages except json it takes 93.074ms but there are no json code blocks on that page. If I only have javascript in as the language it takes 215.406ms as it highllights 24 of 27 code blocks. It really seems to be the amount of work shiki has to do.
Vastly improved after ditching Shiki.
It's improved for sure but we may want to take another pass on this next week.
Maybe we come up with a good target render time for the heaviest page (Node.js runtime helper doc?) and open another issue to see how close we can get.
I think the big thing is to look into cold starts especially when you go to https://arc.codes as you can get back to back cold starts as it redirects to another lambda.
It feels like the responses are taking longer. Others have reported multi-second response times -- not good for something that's 100% static. We should attempt to reproduce locally and attempt some profiling.