2 ms·

Thanks for all the details. I cloned the repo now to take a look. If I see it correctly here, it's a full sveltekit backend that does ssr, and not just used fo

Thanks for all the details. I cloned the repo now to take a look. If I see it correctly here, it's a full sveltekit backend that does ssr, and not just used for serving static files. The +page.ts file has a universal load function so during ssr, the sveltekit backend loads data from the rust backend and later during hydration the client also loads data directly from the rust backend without the requests being proxied through the sveltekit backend. I'm guessing in production one would proxy all requests through the sveltekit backend (or another proxy) as you mentioned. Also, if we would run them both in the same location or in a container, wouldn't it be much better to use unix domain sockets for the IPC?

eddythompson80 1y ago
Yeah, you're probably right if you want ssr. My understanding was that most ssr frameworks have ssr as optional and people fight about the tradeoffs between page load time (better with ssr) vs rps per CPU core (better without ssr). I'm not sure if that's the case with svelte. > Also, if we would run them both in the same location or in a container, wouldn't it be much better to use unix domain sockets for the IPC? Probably in 2006? My understanding was that the localhost tcp stack in linux has been optimized so much, that it's hardly a "network" connection anymore and has no overhead compared to a unix domain. The main difference is that people using unix socket tend to hand roll their communication protocols, but if you're gonna be serving http though a On my desktop $ netperf -H 127.0.0.1 -t TCP_STREAM Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 131072 16384 16384 10.00 35464.47 $ netperf -t STREAM_STREAM Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 2304 212992 212992 10.00 32852.21 so pretty close
- sureglymop 1y ago
  Quite interesting! I get similar results on my machine. But let's also measure latency which is what should show the protocol stack overhead: $ netperf -H 127.0.0.1 -t TCP_RR Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 16384 131072 1 1 10.00 63506.58 16384 131072 $ netperf -t STREAM_RR Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 212992 212992 1 1 10.00 122526.23 4608 2304 But I would agree now that it probably doesn't matter for most applications.

eddythompson80 1y ago

Yeah, you're probably right if you want ssr. My understanding was that most ssr frameworks have ssr as optional and people fight about the tradeoffs between page load time (better with ssr) vs rps per CPU core (better without ssr). I'm not sure if that's the case with svelte. > Also, if we would run them both in the same location or in a container, wouldn't it be much better to use unix domain sockets for the IPC? Probably in 2006? My understanding was that the localhost tcp stack in linux has been optimized so much, that it's hardly a "network" connection anymore and has no overhead compared to a unix domain. The main difference is that people using unix socket tend to hand roll their communication protocols, but if you're gonna be serving http though a On my desktop $ netperf -H 127.0.0.1 -t TCP_STREAM Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 131072 16384 16384 10.00 35464.47 $ netperf -t STREAM_STREAM Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 2304 212992 212992 10.00 32852.21 so pretty close

sureglymop 1y ago
Quite interesting! I get similar results on my machine. But let's also measure latency which is what should show the protocol stack overhead: $ netperf -H 127.0.0.1 -t TCP_RR Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 16384 131072 1 1 10.00 63506.58 16384 131072 $ netperf -t STREAM_RR Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 212992 212992 1 1 10.00 122526.23 4608 2304 But I would agree now that it probably doesn't matter for most applications.