SSR loading time

[mrdotb]

I deployed the last examples on fly and compare the loading time with SSR on / off on the cheapest fly machine with 1 nodejs worker.

SSR on

[info] GET /simple
[info] Sent 200 in 1020ms
[info] GET /simple-props
[info] Sent 200 in 1455ms
[info] GET /typescript
[info] Sent 200 in 1047ms
[info] GET /lazy
[info] Sent 200 in 2442ms
[info] GET /live-counter
[info] Sent 200 in 1517ms 

SSR off

[info] GET /simple
[info] Sent 200 in 13ms
[info] GET /simple
[info] Sent 200 in 11ms
[info] GET /simple-props
[info] Sent 200 in 10ms
[info] GET /typescript
[info] Sent 200 in 10ms
[info] GET /lazy
[info] Sent 200 in 13ms

It's so slow

[fullofcaffeine]

Interesting. Do you think it has to do with the Elixir/Phoenix/BEAM pipeline, nodejs or the fly instance specs? For example, if you were to render the same bits via nodejs directly, would you get a similar throughput in the same fly.io machine?

[Valian]

I've created a PR that might help pin this down #18

[mrdotb]

I investigated more using the fly grafana dashboard. So running 1 Nodejs worker + the phoenix app on 256 MiB leave a very low amount of free memory. 2.55 MiB here. For some reason I can't seems to reproduce the slow latency I experienced last time this time it OOM directly. The slow rendering I experienced is probably related to the page cache since swap is Off.

Putting 512 MiB of memory solve the OOM and latency making the rendering time close to raw phoenix.

2024-10-20T12:53:30Z GET /simple-props
2024-10-20T12:53:30Z SSR completed for component: SimpleProps in 1942µs
2024-10-20T12:53:30Z SSR completed for component: GithubCode in 2122µs
2024-10-20T12:53:30Z SSR completed for component: GithubCode in 1796µs
2024-10-20T12:53:32Z  Sent 200 in 11ms

[mrdotb]

77c3ca955431daf5bb9759add642353d3949b3be Document that at least 512Mib is needed