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.

Sign up for GitHub

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

Jump to bottom

Docs for server timing #125

Open
tkadlec opened this issue Aug 29, 2024 · 3 comments
Open

Docs for server timing #125

tkadlec opened this issue Aug 29, 2024 · 3 comments

Comments

@tkadlec
Copy link

tkadlec commented Aug 29, 2024

I love seeing some server timings in enhance, but I can't find any documentation about what they each mean.

Would it be possible to get some docs for what each of these are measuring:

  • enhance-api
  • enhance-elements
  • enhance-html
  • enhance-preflight

In particular enhance-elements and enhance-html as those two are the ones that take the longest (at least in my current situation).
@tbeseda
Copy link
Contributor

tbeseda commented Aug 30, 2024

That's a great callout!
I'll outline those here and we can add to the docs shortly.

enhance-preflight
times your preflight function (if one exists)
src
enhance-api
times your route's api function (if one exists)
src
enhance-elements
times the search and load for your elements, and possibly Enhance's defaults like <head>
src
enhance-html
times the call the enhance-ssr given that the elements have been loaded and initial state is ready
src

Note: these enhance-* timers do not overlap, but not all timers that are present are exclusive of each other. Basically, they don't all have to add up to the total server time.

What sort of times are you seeing for elements and html?

-elements scales as your element count goes up. Should be linear. I believe it's cached; so requests when the server is "warm" should show quicker times.
That said, we have been working on ways to speed that up - but it hasn't been too painful in our tests... yet.

I have found -html to slow down when each element has its own <style> block. It's definitely something I'd like to make faster but I think it relates to our CSS parsing, so that may be a bigger change.

@tkadlec
Copy link
Author

tkadlec commented Aug 30, 2024

Yeah, it definitely does cache. When it's not cached, I've been seeing some in the 300-400ms range, but I'm not super worried about it because the caching seems pretty solid and frankly the bigger issue are the dynamoDB queries themselves.

@tkadlec
Copy link
Author

tkadlec commented Sep 5, 2024

Just wanted to say this was wildly helpful, @tbeseda. I stumbled on a route with very high TTFB. Looking at the server timings, enhance-api as killing me (2+ seconds). I wrapped my route methods in my own server timing codes, and they were nowhere near that 2s (~240ms). Got me thinking about what else might be an issue and got a hunch that maybe it was the data added to the response.

Sure enough, stumbled on a massive chunk of data that was being added, that I wasn't even using at all. Removed that, the 2s enhance-api dropped to 300ms. 💪

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tbeseda @tkadlec